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

Re: [Xen-devel] [RFH]: AMD CR intercept for lmsw/clts

>>> On 05.08.14 at 13:16, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 05/08/2014 08:46, Jan Beulich wrote:
>> I'd prefer this - it seems pretty ugly to me that handle_mmio()/
>> x86_emulate() gets used for this purpose - but am not certain this
>> will actually work out nicely for other than CLTS: All the
>> instructions currently handled specially are ones with fixed
>> operands, and only CLTS fits that.
>> You'll btw have the same problem with SMSW and DRx accesses,
>> string I/O instructions, as well as (on older CPUs) with moves to/from
>> CRx and INVLPG.
> SMSW certainly, but what is wrong with the others?  For those, the exit
> info appears to give fully decoded information.

All the decoding info is conditional upon decoding assists being
available. And for string I/O handle_mmio() is being used kind of

>> In the case this doesn't turn out reasonable, rather than
>> manipulating handle_mmio() any further, I'd suggest to investigate
>> bypassing that function in favor of a more direct access to the x86
>> emulator. After all you're not after any MMIO emulation here, just
>> bare instructions (many of which without memory operands at all).
> In the AMD System manual (vol 2), there are special cases listed for
> lmsw, clts and smsw in section 15.8.1.  In each case, bit 63 of
> exitinfo1 will be clear (which is checked using magic numbers in the
> code).  It would appear that under these circumstances, the only
> information provided is "it wasn't a mov instruction".

Right, except that at least for CLTS (not having any operands) the
light weight decoding could still be used. I'd even think decoding the
CRx/DRx moves would be okay as they only permit register
operands. But with LMSW and SMSW having memory operands it
would indeed start to become like re-implementing x86_emulate().
Question is whether one couldn't simply forbid PVH guests to use
them, as moves to/from CR0 provide all the needed functionality.


Xen-devel mailing list



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