On Mon, Oct 27, 2008 at 08:02:31AM -0700, Eric W. Biederman wrote: > Avi Kivity <[EMAIL PROTECTED]> 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 -- 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