Eric W. Biederman wrote:
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.
Mostly likely any reboot path will trigger software to toggle the
reset line on the board. At least that has been my experience, and
the reason we don't see many problems when we fail to properly
shutdown devices before reboot. If vmx persists across that it would
seem to be very broken by design.
We've observed on some machines that keyboard controller reset didn't
work, and that the fallback to triple-fault asserted INIT and not RESET
(and that this INIT was blocked, hanging the machine). Switching to
acpi reset worked on some machines, but not all. Either acpi reset was
not implemented on the failing machines, or it was wired to INIT and not
RESET.
My objections are: on_each_cpu called from after a panic looks like
a good way to loose control of the box and never return. Adding
a notifier looks like a good way too add functionality onto the
kdump path that never gets reviewed for robustness after a kernel
crash and thus a good way to remove the usefulness of the kexec
on panic kernel path.
Since we already have NMI IPIs, we could disable vmx there. If it is
done unconditionally and without notifiers, there is no chance of having
unreviewed surprises sneaking in.
--
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
