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

[Eduardo Habkost <ehabkost@redhat.com>]

On Mon, Oct 27, 2008 at 08:02:31AM -0700, Eric W. Biederman wrote:
> Avi Kivity <avi@redhat.com> writes:
> 
> > Eric W. Biederman wrote:
> >
> > 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.
> 
> Right.  INIT does not reset things like the MTRRs, I had forgotten
> that distinction.
> 
> Frequently the firmware when it regains control at 0xffffffff0
> asserts reset, but if we can't get there.  Ouch!
> 
> 
> > 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.
> 
> Sounds good to me.

The problem here is that we can't disable it unconditionally,
so we need to either hack into #UD,  or track on which CPUs it is
enabled. But tracking on which CPUs it is enabled is exactly what KVM
hardware_enable()/hardware_disable() do.

To avoid hacking into #UD only for that, I was being inclined to simply
add core code to track on which CPUs vmx is enabled. But just calling
back into KVM doesn't look too bad, as long as the callback does only
what is strictly necessary. It looks a bit better than moving kvm code
to the core, and looks simple enough to be better than hacking #UD.

Maybe we could have a simple virt-specific callback pointer instead of
a whole notifier chain?

-- 
Eduardo

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