On 09/03/2011 12:50 AM, Jeremy Fitzhardinge wrote:
On 09/02/2011 01:47 PM, Peter Zijlstra wrote: > On Fri, 2011-09-02 at 12:29 -0700, Jeremy Fitzhardinge wrote: >>> I know that its generally considered bad form, but there's at least one >>> spinlock that's only taken from NMI context and thus hasn't got any >>> deadlock potential. >> Which one? > arch/x86/kernel/traps.c:nmi_reason_lock > > It serializes NMI access to the NMI reason port across CPUs. Ah, OK. Well, that will never happen in a PV Xen guest. But PV ticketlocks are equally applicable to an HVM Xen domain (and KVM guest), so I guess there's at least some chance there could be a virtual emulated NMI. Maybe? Does qemu do that kind of thing?
kvm does. In fact, I want to use 'hlt' for blocking vcpus in the slowpath and an NMI IPI for waking them up. That's not going to work in an NMI, but I guess I can replace the 'hlt' with a 'pause' if we're in an NMI, and just spin there.
btw, doing a race-free NMI wakeup is going to be interesting - we'll have to look at %rip and see if is just before our hlt, since there's no magic sti; hlt sequence we can use.
-- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
