[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH V2] xen: vmx: Use an INT 2 call to process real NMI's instead of self_nmi() in VMEXIT handler


  • To: Mats Petersson <mats.petersson@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxx>
  • Date: Fri, 16 Nov 2012 10:18:22 +0000
  • Delivery-date: Fri, 16 Nov 2012 10:18:45 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: Ac3D47Sv7KN2kY7s4Umglc/lAeT6XQ==
  • Thread-topic: [Xen-devel] [PATCH V2] xen: vmx: Use an INT 2 call to process real NMI's instead of self_nmi() in VMEXIT handler

On 16/11/2012 09:59, "Mats Petersson" <mats.petersson@xxxxxxxxxx> 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



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.