Re: [PATCH 1/1 V3] x86/AMD: Fix nested svm crash due to assertion in __virt_to_maddr

From: "Egger, Christoph" <chegger@amazon.de>
To: Tim Deegan <tim@xen.org>
Cc: Jan Beulich <JBeulich@suse.com>,
	suravee.suthikulpanit@amd.com, xen-devel@lists.xen.org
Subject: Re: [PATCH 1/1 V3] x86/AMD: Fix nested svm crash due to assertion in __virt_to_maddr
Date: Thu, 18 Jul 2013 10:24:36 +0200	[thread overview]
Message-ID: <51E7A644.3010506@amazon.de> (raw)
In-Reply-To: <51E7A3E0.4080306@amazon.de>

On 18.07.13 10:14, Egger, Christoph wrote:
> On 17.07.13 21:43, Tim Deegan wrote:
>>> I'm not clear about the need for this new wrapper: Is it really
>>> benign to the caller what type, access, and order get returned
>>> here? Is it really too much of a burden to have the two call
>>> sites do the call here directly? The more that (see above) you'd
>>> really need to give the caller control over the access requested?
>>
>> Yeah, I'm not sure the wrapper is needed.  Can the callers just use
>> get_page_from_gfn() to do the translation from guest-MFN -- i.e. will we
>> always be in non-nested mode when we're emulating VMLOAD/VMSAVE?
> 
> When you run an L2 hypervisor then you are in nested mode.

Continue thinking...
in this case the l1 hypervisor emulates VMLOAD/VMSAVE.
The l1 hypervisor is in non-nested mode. When the l1 hypervisor will use
the VMLOAD/VMSAVE instructions they get intercepted and will be
emulated by the host hypervisor and is in non-nested mode.

Tim: The answer to your question is yes, we are always in non-nested
mode when we're emulating VMLOAD/VMSAVE
while at intercept time we are not always in non-nested mode.

Christoph