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

From: Avi Kivity
Date: Fri Jul 16 2010 - 12:48:11 EST


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/