Messages in this thread | | | Date | Fri, 16 Jul 2010 19:47:08 +0300 | From | Avi Kivity <> | Subject | Re: [patch 2/2] x86 NMI-safe INT3 and Page Fault |
| |
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.
| |