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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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
unconditionally.

>> 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.

Jan


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