Re: [PATCH 0/2] kvm: disable virtualization on kdump

[Avi Kivity <avi@redhat.com>]

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


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec