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

[Vivek Goyal <vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On Mon, Oct 27, 2008 at 10:54:01AM +0200, Avi Kivity wrote:
> Eduardo Habkost wrote:
>>> (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.
>>
>>   
>
> That looks like the easiest (and best) way out.
>
>> 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,
>
> I think an unconditional vmx disable is wanted here, so kexec can work  
> with other hypervisors.
>
>>  but then it wouldn't work when KVM is compiled as a
>> out-of-tree module.
>>   
>
> The external module can do without.  It's possible to hijack the nmi  
> vector, but I don't think that's a good idea.  If someone wants  
> kexec+vmx on an older kernel, they can patch that kernel.
>
>>> 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.
>>   
>
> The hang was likely caused by vmx blocking INIT.  Sigh.

Avi,

We boot kdump kernel with maxcpus=1. IIUC, in that code path we will not
be using INIT. So did you try booting kdump kernel with maxcpus=1 and did
it work for you? If not than problem could be something else.

Thanks
Vivek

>
> -- 
> error compiling committee.c: too many arguments to function