Eduardo Habkost wrote:
(we can use NMI IPIs, but that will likely be messy)
NMI IPIs are already used on x86 native_machine_crash_shutdown(), so
it wouldn't get more messy that it is currently. We just need to add
another bit of code to the code that already runs on an NMI handler.
That looks like the easiest (and best) way out.
My question is: is a notifier chain too much complexity for a sensible
piece of code like that? If so, a compile-time hook on that point
would be safer,
I think an unconditional vmx disable is wanted here, so kexec can work
with other hypervisors.
but then it wouldn't work when KVM is compiled as a
out-of-tree module.
The external module can do without. It's possible to hijack the nmi
vector, but I don't think that's a good idea. If someone wants
kexec+vmx on an older kernel, they can patch that kernel.
But what happens when the kdump kernel reboots? If it is uniprocessor,
it will never have a chance to disable vmx on other cpus. Using acpi
reset (now default) works around this on some machines, but not all.
Good point. My problem was a hang when booting the kdump kernel, but it
may also cause problems later, when the kdump kernel reboots.
The hang was likely caused by vmx blocking INIT. Sigh.
--
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
