From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Egger, Christoph" 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 Message-ID: <51E7A644.3010506@amazon.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51E7A3E0.4080306@amazon.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan Cc: Jan Beulich , suravee.suthikulpanit@amd.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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