From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH V2] xen: vmx: Use an INT 2 call to process real NMI's instead of self_nmi() in VMEXIT handler Date: Fri, 16 Nov 2012 10:18:22 +0000 Message-ID: References: <50A60E8C.9070608@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <50A60E8C.9070608@citrix.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: Mats Petersson , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 16/11/2012 09:59, "Mats Petersson" wrote: >>> Yes, I hadn't thought of that case. >> But what would make a fault happen on that IRET? Oh, yes, >> there is one case - the guest having its previous instruction end >> exactly at the canonical/non-canonical boundary. But for the >> sake of correctness, that's a #GP then. I would suppose this >> would better be filtered (manually injecting a #GP into the guest) >> than allowed to actually cause a #GP. > Or, if for some reason the address we return to is "not present". Now, > in the current Xen, Xen itself doesn't get paged out, but in a PV guest, > I'm pretty certain the guest could decide to page out some code-page, > which just happens to be the one we were about to return to? That fault would occur in the context being returned to, with rIP == the IRET return target. -- Keir