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
