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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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:
>     case VMEXIT_CR0_WRITE ... VMEXIT_CR15_WRITE:
>         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.

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

Jan


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