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

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

Eduardo Habkost wrote:
> Can't we just set a flag when we are about to enable vmx, so we run vmxoff
> only when know it's enabled? There will be a tiny window between setting
> this flag and and actually running vmxon where things could go wrong,
> but this doesn't look that bad.
>   

It makes more sense to have a vmxon api in the core; you call it, the 
kernel enables it and sets a flag; then either you or the core can 
disable it.

> Having to handle #UD would make things more messy, in my opinion.
>   

It's not too bad, either relying on exception handlers or hacking our own.

> BTW, is this problem vmx-specific? Do we need to do something similar
> for svm?
>
>   

svm needs it as well, since it shares some memory with the cpu.  It's 
less critical though, will likely work even without it.

>> 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).
>>     
>
> I think we can't fully trust anything if we are on the crash dump path,
> so the less code we depend on, the better.
>   

So we can point #UD temporarily at an 'addq $3, (%rsp); iret' for the 
vmxoff instruction.  Or implement the 'enable virt extensions' API.

> The patches I've sent to the kvm mailing list added a notifier interface
> specific for kexec_crash, using raw_notifier_*().
>
> IMO, if a notifier registration interface was acceptable, the raw
> notifiers would be good enough for that. But Eric seems to think that
> adding a notifier registration interface for the crash handler path
> wouldn't be a good idea, and I am starting to agree with him.
>
>   

I wouldn't mind notifiers (with a nice comment explaining that you must 
know what you're doing, though that's the case with most kernel APIs).  
I'm fine with either approach.

>> The general kexec path also wants this fixed.
>>     
>
> When I've tested it, kexec called the kvm reboot notifier, so
> everything worked fine.
>   

Oh, okay.

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

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