Re: [Xen-devel] [PATCH 2/2] x86emul: adjust MOVSXD source operand handling

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Juergen Gross" <jgross@suse.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86emul: adjust MOVSXD source operand handling
Date: Wed, 2 Oct 2019 09:51:08 +0100	[thread overview]
Message-ID: <ce240495-a64f-db54-4162-890d0c524df7@citrix.com> (raw)
In-Reply-To: <9ee0114c-41ba-5d8e-1aef-5bccf1fb15dc@suse.com>

On 02/10/2019 08:07, Jan Beulich wrote:
> On 01.10.2019 21:44, Andrew Cooper wrote:
>> In this example, hardware can the emulator can disagree by using a
>> different access width.
>>
>> I've been experimenting with my Rome system, and an emulator hardcoded
>> to use 2-byte accesses.  After some investigation, the livelock only
>> occurs for access-rights faults.  Translation faults get identified as
>> not a shadow fault, and bounced back to the guest.
>>
>> Shadow guests can use PKRU, so can generate an access fault by marking
>> the page at 0x2000 as no-access, so I think that in principle, this
>> change will result in a new latent livelock case, but I can't actually
>> confirm it.
> I think I see what you mean, but then I don't see how this is an
> argument against the patch in its current shape: It actually
> reduces the cases of disagreement between hardware and emulator.

At the moment, the emulator is strictly 4 bytes, and hardware may be 4
or 2.  Therefore, there is no chance of the pipeline yielding #PF while
the emulator yielding OK.

With the change in place, older Intel parts which do use a 4 byte access
now come with a risk of livelock.  Whichever parts these are, they
predate PKRU so in this specific case, the problem is only theoretical
AFAICT.

Also, in this specific case, Intel's warning of "Don't use this
instruction without a REX prefix" means that we shouldn't see it in
anything but test scenarios.

> One possibility to make a further step in that direction would
> be to make behavior dependent upon the underlying hardware's
> vendor, rather than the one the guest sees.

I considered this.  It would work on native (at the expense of
complicating the emulator), but won't work properly if Xen is
virtualisied and migrated.  I can't see a way around this.

Furthermore, we can't execute the instruction against a mapping of the
guest, because the problem here is determining the width of the access,
which is information needed to construct the mapping in the first place.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel