[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/2014 08:46, Jan Beulich wrote:
>>>> On 05.08.14 at 03:33, <mukesh.rathor@xxxxxxxxxx> wrote:
>> Hi,
>> On AMD, clts/lmsw will cause "mov cr" vmexit, but unlike intel, they
>> can't be handled via svm_vmexit_do_cr_access and are emulated thru
>> handle_mmio() which is a problem for pvh because of:
>> handle_mmio():
>> ..
>>     ASSERT(!is_pvh_vcpu(curr));
>> AMD CR intercepts in svm.c:
>>     case VMEXIT_CR0_READ ... VMEXIT_CR15_READ:
>>         if ( cpu_has_svm_decode && (vmcb->exitinfo1 & (1ULL << 63)) )
>>             svm_vmexit_do_cr_access(vmcb, regs);
>>         else if ( !handle_mmio() )     <==========
>>             hvm_inject_hw_exception(TRAP_gp_fault, 0);
>>     break;
>> Soooo, this leaves no choice but to make the ASSERT conditional
>> for intel only, and let handle_mmio go thru x86_emulate and let
>> x86_emulate fail for anything other than lmsw/clts? I was thinking
>> something like:
>> x86_emulate()
>>   int fail_pvh_emul = 1;
>>   ...
>>   case lmsw/clts:
>>      .....
>>      fail_pvh_emul = 0;
>> then
>>  done:
>>      if (fail_pvh_emul)
>>          rc = X86EMUL_UNHANDLEABLE;
>>      return rc;
> I'd strongly recommend against adding any such to x86_emulate():
> There's nothing precluding the emulator to be used for PVH guests.
>> Or, should I just create a new function for clts/lmsw and call it
>> directly from vmexit switch itself?
> 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.

> 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".  As a result, I
think x86_emulate() is the best way go to, rather than hacking something
up locally, although I would agree that handle_mmio() is not really


Xen-devel mailing list



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