From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tim Deegan <tim@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 17:41:08 +0100
Message-ID: <20130718164108.GA94768@ocelot.phlegethon.org>
References: <1373564054-4293-1-git-send-email-suravee.suthikulpanit@amd.com>
	<51DFD3EC02000078000E45BB@nat28.tlf.novell.com>
	<20130717194359.GB80836@ocelot.phlegethon.org>
	<51E7A3E0.4080306@amazon.de> <51E7A644.3010506@amazon.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <51E7A644.3010506@amazon.de>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: "Egger, Christoph" <chegger@amazon.de>
Cc: suravee.suthikulpanit@amd.com, Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

At 10:24 +0200 on 18 Jul (1374143076), Egger, Christoph wrote:
> 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

Good -- so in that case we can use get_page_from_gfn(P2M_ALLOC|P2M_UNSHARE).
The callers should also check that p2m_is_ram() && !p2m_is_readonly()
on the returned type.

Cheers,

Tim.