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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

And I didn't say anything to the contrary. All I said was that there is
another use of handle_mmio() lurking.

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

Generally I would agree. For those two specific instructions though,
I don't think any reasonably modern OS would be using them
anyway outside of 16-bit boot code. After adding to this the fact
that PVH, just like PV, implies a modified OS, putting on such a
restriction doesn't seem very harmful to me.

Jan


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