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

From: Avi Kivity <avi@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andrew Morton <akpm@osdl.org>,
	Eduardo Habkost <ehabkost@redhat.com>,
	kvm@vger.kernel.org, kexec@lists.infradead.org,
	Haren Myneni <hbabu@us.ibm.com>,
	Simon Horman <horms@verge.net.au>,
	Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH 0/2] kvm: disable virtualization on kdump
Date: Mon, 27 Oct 2008 11:13:41 +0200	[thread overview]
Message-ID: <49058645.9010005@redhat.com> (raw)
In-Reply-To: <m1bpx6bxhm.fsf@frodo.ebiederm.org>

Eric W. Biederman wrote:
>> 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.
>>     
>
> Yes.  And handling of those NMIs is best effort.  Nothing fails if
> they don't actually run.
>
>   

Unless someone can come up with another way to disable vmx remotely, 
that's going to change if you have vmx enabled.

> Well we could fairly easily have a non-modular function that does.
> if (vmx_present && vmx_enabled) {
>    turn_off_vmx();
> }
>
> Which at first skim looks like it is all of about 10-20 machine
> instructions.
>
>   

There's no way to query whether vmx is enabled or disabled, AFAICT.  So 
we have to execute vmxoff and ignore possible #UDs.

If we trust the exception handlers, there's no problem.  Otherwise we 
need to replace the current #UD handler with an iret (perhaps switching 
temporarily to another IDT).

> There are a few real places where we need code on the kdump
> path because there it is not possible to do the work any
> other way.  However we need to think long and hard about
> that because placing the code anywhere besides in a broken
> and failing kernel is going to be easier to maintain and
> more reliable.
>   

vmx blocking INITs makes it impossible to leave this to the new kernel.

> I oppose an atomic notifier because it makes the review
> essentially impossible.  If any module can come in and register
> a notifier we can't know what code is running on that code
> path and we can't be certain the code is safe in an abnormal
> case to run on that code path.
>   

What if it's a specialized notifier for kexec?  Or even kexec_crash?

That said, I have no issue with static code at the call site.

> Right now we only need to support vmx on the kdump path because
> of what appears to be a hardware design bug.  Enabling vmx
> apparently disables standard functions like an INIT IPI.  Things
> like this do happen but they should be rare.
>   

The general kexec path also wants this fixed.

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

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