From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Egger, Christoph" Subject: Re: hap_invlpg() vs INVLPGA Date: Fri, 29 Jan 2016 14:57:11 +0100 Message-ID: <56AB6FB7.7030003@amazon.de> References: <56AB761F02000078000CC667@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aP9Yz-0006AE-Um for xen-devel@lists.xenproject.org; Fri, 29 Jan 2016 13:58:14 +0000 In-Reply-To: <56AB761F02000078000CC667@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 29/01/16 14:24, Jan Beulich wrote: > Christoph, > > in commit dd6de3ab99 ("Implement Nested-on-Nested") you added > code to hap_invlpg() supposedly emulating INVLPGA. I've been > stumbling across this a number of times in the past, not being able > to make the connection between (a) VMX/EPT and INVLPGA and > (b) SVM's INVLPGA intercept and this function. When you boot Windows 7 as L1 guest and XP-Mode as L2 guest then L2 guest uses INVLPG instruction to invalidate a page and L1 guest handles this via using INVLPGA instruction. The INVLPG intercept flushes the nested hap p2m which is effectively a TLB flush to the L1 guest. Then this intercept is injected into L1 guest. The INVLPGA instruction enforces a new ASID. If the nested hap p2m is NULL then p2m_flush() should effectively be a noop but it may not crash the guest. What I don't remember is if Windows 7 must be 32bit or 64bit to reproduce this. Christoph > I'm asking in the context of a reported crash resulting from the > nv_p2m field being NULL during emulation of an INVLPG instruction > in a guest with nesting enabled but - afaict - not actually used. Of > course I could submit a patch adding a NULL check here, but I'd > like to understand what this code is for, and hence whether the > better fix wouldn't be to get rid of it. > > Jan Amazon Development Center Germany GmbH Berlin - Dresden - Aachen main office: Krausenstr. 38, 10117 Berlin Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger Ust-ID: DE289237879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B