You need to save/restore cr2 in addition, otherwise the following hits youOK, just to make sure: you mean we'd have to save/restore the cr2 register
- 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.
at the beginning/end of the NMI handler execution, right ?
The shouldn't we
save/restore cr3 too ?
But the whole thing strikes me as overkill. If it's 8k per-cpu, what'sWell, it seems like all the kernel code calling "vmalloc_sync_all()" (which is
wrong with using a per-cpu pointer to a kmalloc() area?
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.