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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 05/08/2014 13:11, Jan Beulich wrote:
>>>> On 05.08.14 at 13:16, <andrew.cooper3@citrix.com> 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.

The decode assists apply strictly to mov CRx/DRx, INTn, INVLPG and
(nested) #PF.  In contrast, the IOIO intercept appears to
unconditionally fill the decode information in exitinfo1, so I believe
the current code is correct.

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

I think that is a very dangerous route to take.

Despite the current limitations, I firmly believe that PVH should be HVM
- device model, rather than PV + VMX/SVM.  Restricting the use of
certain instructions would certainly move PVH into the latter category.

Fundamentally, the end goal of PVH needs deciding ASAP, and documenting,
to help guide decisions like this.

~Andrew