On Fri, Apr 29, 2016 at 12:39:16PM -0700, Andy Lutomirski wrote:
> On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf wrote:
> > Thanks to all the recent x86 entry code refactoring, most tasks' kernel
> > stacks start at the same offset right above their saved pt_regs,
> > regardless of which syscall
On Fri, Apr 29, 2016 at 01:32:53PM -0700, Andy Lutomirski wrote:
> On Fri, Apr 29, 2016 at 1:27 PM, Josh Poimboeuf wrote:
> > On Fri, Apr 29, 2016 at 01:19:23PM -0700, Andy Lutomirski wrote:
> >> On Fri, Apr 29, 2016 at 1:11 PM, Josh Poimboeuf
> >> wrote:
> >> > On Fri, Apr 29, 2016 at 11:06:53A
On Fri, Apr 29, 2016 at 2:25 PM, Josh Poimboeuf wrote:
> On Fri, Apr 29, 2016 at 01:32:53PM -0700, Andy Lutomirski wrote:
>> On Fri, Apr 29, 2016 at 1:27 PM, Josh Poimboeuf wrote:
>> > On Fri, Apr 29, 2016 at 01:19:23PM -0700, Andy Lutomirski wrote:
>> >> On Fri, Apr 29, 2016 at 1:11 PM, Josh Poi
On Fri, Apr 29, 2016 at 1:50 PM, Josh Poimboeuf wrote:
> On Fri, Apr 29, 2016 at 12:39:16PM -0700, Andy Lutomirski wrote:
>> On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf wrote:
>> > Thanks to all the recent x86 entry code refactoring, most tasks' kernel
>> > stacks start at the same offset rig
On Fri, 29 Apr 2016, Andy Lutomirski wrote:
> > NMI, MCE and interrupts aren't a problem because they have dedicated
> > stacks, which are easy to detect. If the tasks' stack is on an
> > exception stack or an irq stack, we consider it unreliable.
>
> Only on x86_64.
Well, MCEs are more or less
In create_zero_mask() we have:
addi%1,%2,-1
andc%1,%1,%2
popcntd %0,%1
using the "r" constraint for %2. r0 is a valid register in the "r" set,
but addi X,r0,X turns it into an li:
li r7,-1
andcr7,r7,r0
popcntd r4,r7
Fix this by us
On Fri, Apr 29, 2016 at 02:37:41PM -0700, Andy Lutomirski wrote:
> On Fri, Apr 29, 2016 at 2:25 PM, Josh Poimboeuf wrote:
> > I think the easiest way to make it work would be to modify the idtentry
> > macro to put all the idt entries in a dedicated section. Then the
> > unwinder could easily det
On Sat, Apr 30, 2016 at 12:11:45AM +0200, Jiri Kosina wrote:
> On Fri, 29 Apr 2016, Andy Lutomirski wrote:
> > > NMI, MCE and interrupts aren't a problem because they have dedicated
> > > stacks, which are easy to detect. If the tasks' stack is on an
> > > exception stack or an irq stack, we consi
On Fri, Apr 29, 2016 at 02:38:02PM -0700, Andy Lutomirski wrote:
> On Fri, Apr 29, 2016 at 1:50 PM, Josh Poimboeuf wrote:
> > On Fri, Apr 29, 2016 at 12:39:16PM -0700, Andy Lutomirski wrote:
> >> On Thu, Apr 28, 2016 at 1:44 PM, Josh Poimboeuf
> >> wrote:
> >> > Thanks to all the recent x86 entr
On 04/28/16 at 03:44P, Josh Poimboeuf wrote:
> In preparation for being able to determine whether a given stack trace
> is reliable, allow the stacktrace_ops functions to propagate errors to
> dump_trace().
Hi, Josh.
Have you considered to make walk_stack function as non-return function,
since th
On 04/29/2016 04:22 PM, Christopher Covington wrote:
On 04/28/2016 02:53 PM, Andy Lutomirski wrote:
Also, at some point, possibly quite soon, x86 will want a way for
user code to ask the kernel to map a specific vdso variant at a specific
address. Could we perhaps add a new pair of syscalls:
st
On Thu, Apr 28, 2016 at 4:44 PM, Josh Poimboeuf wrote:
> Thanks to all the recent x86 entry code refactoring, most tasks' kernel
> stacks start at the same offset right above their saved pt_regs,
> regardless of which syscall was used to enter the kernel. That creates
> a nice convention which ma
On Apr 29, 2016 3:41 PM, "Josh Poimboeuf" wrote:
>
> On Fri, Apr 29, 2016 at 02:37:41PM -0700, Andy Lutomirski wrote:
> > On Fri, Apr 29, 2016 at 2:25 PM, Josh Poimboeuf wrote:
> > > I think the easiest way to make it work would be to modify the idtentry
> > > macro to put all the idt entries in
On Apr 29, 2016 3:11 PM, "Jiri Kosina" wrote:
>
> On Fri, 29 Apr 2016, Andy Lutomirski wrote:
>
> > > NMI, MCE and interrupts aren't a problem because they have dedicated
> > > stacks, which are easy to detect. If the tasks' stack is on an
> > > exception stack or an irq stack, we consider it unr
On Apr 29, 2016 4:27 PM, "Josh Poimboeuf" wrote:
>
> On Fri, Apr 29, 2016 at 02:38:02PM -0700, Andy Lutomirski wrote:
> > On Fri, Apr 29, 2016 at 1:50 PM, Josh Poimboeuf wrote:
> > > On Fri, Apr 29, 2016 at 12:39:16PM -0700, Andy Lutomirski wrote:
> > >> On Thu, Apr 28, 2016 at 1:44 PM, Josh Poim
We don't support transactional memory in PR KVM, so don't tell
the OS that we do.
Signed-off-by: Anton Blanchard
---
v2: Fix build with CONFIG_KVM disabled, noticed by Alex.
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index b69995e..dc3e3c9 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -
101 - 116 of 116 matches
Mail list logo
