Re: [patch 2/2] x86 NMI-safe INT3 and Page Fault

[Avi Kivity]

On 07/16/2010 05:49 PM, Mathieu Desnoyers wrote:
> > You need to save/restore cr2 in addition, otherwise the following hits you
> >
> > - page fault
> > - processor writes cr2, enters fault handler
> > - nmi
> > - page fault
> > - cr2 overwritten
> >
> > I guess you would usually not notice the corruption since you'd just see
> > a spurious fault on the page the NMI handler touched, but if the first
> > fault happened in a kvm guest, then we'd corrupt the guest's cr2.
> >      
> OK, just to make sure: you mean we'd have to save/restore the cr2 register
> at the beginning/end of the NMI handler execution, right ?

Yes.

> The shouldn't we
> save/restore cr3 too ?
>
>    

No, faults should not change cr3.

> > But the whole thing strikes me as overkill.  If it's 8k per-cpu, what's
> > wrong with using a per-cpu pointer to a kmalloc() area?
> >      
> Well, it seems like all the kernel code calling "vmalloc_sync_all()" (which is
> much more than perf) can potentially cause large latencies, which could be
> squashed by allowing page faults in NMI handlers. This looks like a stronger
> argument to me.

Why is that kernel code calling vmalloc_sync_all()?  If it is only NMI 
which cannot take vmalloc faults, why bother?  If not, why not?

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/