On Sun, Oct 26, 2008 at 05:07:45PM +0200, Avi Kivity wrote: > Eric W. Biederman wrote: <snip> >>>> Is it possible to disable vmx mode before we enable interrrupts in the >>>> kdump kernel? >>>> >>>> >>> You need IPIs to disable vmx on smp. >>> >> >> Thank you. Reading your description and taking a quick look at >> the code in hardware disable it does not appear that there is >> anything needed (other than restricting ourselves it running >> uniprocessor in the kdump kernel) that needs to happen. >> >> Certainly it would be nice to have kvm disabled in hardware, >> but if you are proposing using the existing hardware disable >> I must say that the cure looks much worse than the disease. >> > > Certainly you don't want to issue IPIs when kdump()ing. It's not > unlikely that the other cpus have interrupts permanently disabled. > > (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. 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, but then it wouldn't work when KVM is compiled as a out-of-tree module. > >> It looks like the disable function is all of about 20 assembly >> instructions so I would not have a problem if he had a >> little inline function we could call that test to see if >> vmx is enabled and disable it in the case of kexec on panic. >> >> The normal polite shutdown. That just looks like asking for trouble. >> > > 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. -- Eduardo
