Re: [Xen-devel] there is no sysret in X86_emulate, why?

[hanyandong <hanyandong@xxxxxxxxx>]

> -----原始邮件-----
> 发件人: "Egger, Christoph" <chegger@xxxxxxxxx>
> 发送时间: 2014年10月30日 星期四
> 收件人: "Jan Beulich" <JBeulich@xxxxxxxx>, hanyandong <hanyandong@xxxxxxxxx>
> 抄送: xen-devel@xxxxxxxxxxxxx
> 主题: Re: [Xen-devel] there is no sysret in X86_emulate, why?
> 
> On 2014/10/30 12:04, Jan Beulich wrote:
> >>>> On 30.10.14 at 02:46, <hanyandong@xxxxxxxxx> wrote:
> >> (1)In x86_emulate(), there are sysenter/sysexit, syscall. But why no sysret?
> > 
> > Perhaps on the basis that this already when introduced was only
> > meant to be usable on 64-bit hypervisors, and 64-bit capable CPUs
> > always support SYSRET (whereas the scope of support for the
> > other three varies)? Christoph, you added that code years ago - is
> > there any other explanation for this?
> 
> Back at that time I was working on live migration between AMD and Intel
> forth and back. The sysenter/sysexit emulation covers the case of
> running 32bit binaries in compat mode in a 64bit DomU.
> The syscall emulation also covers a case I do not remember anymore.
> 
> Christoph

thank you.

if I want to intercept sysenter/sysexit, what I need pay  attention to?

I set GUEST_SYSENTER_CS to 0x0, then sysenter/sysexit will triggle a #GP, then will trap into Xen.

for_each_vcpu(d,v)
{
vmx_vmcs_enter(v);
d->arch.hvm_domain.mitctl_op.imaginary_sysenter_cs  =  __vmread(GUEST_SYSENTER_CS);
d->arch.hvm_domain.mitctl_op.forced_sysenter_cs = 0x0;
/*setXentotrap #GP */
__vmwrite(EXCEPTION_BITMAP, __vmread(EXCEPTION_BITMAP) | (1U<<TRAP_gp_fault) );
/*load0x0toGUEST_SYSENTER_CS, next sysenter/sysexit will trap into Xen  for #GP*/
__vmwrite(GUEST_SYSENTER_CS, 0x0);
vmx_vmcs_exit(v);
}

In xen, at vmx_vmexit_handler(), I hanlde #GP as below

caseTRAP_gp_fault:
{

__vmwrite(GUEST_SYSENTER_CS, current->domain->arch.hvm_domain.mitctl_op.imaginary_sysenter_cs);
vmx_vmexit_syscall_intercept(regs); 
__vmwrite(GUEST_SYSENTER_CS, 0x0);      
break;

}

/* use Xen code to emulated sysenter/syexit */
static void vmx_vmexit_syscall_intercept(struct cpu_user_regs *regs)
{
    struct hvm_emulate_ctxt ctxt;
    int rc;

    hvm_emulate_prepare(&ctxt, regs);

    rc = hvm_emulate_one(&ctxt);

    switch ( rc )
    {
        case X86EMUL_UNHANDLEABLE:
            printk("X86EMUL_UNHANDLEABLE\n");
            vmx_inject_hw_exception(TRAP_gp_fault, HVM_DELIVER_NO_ERROR_CODE);
            break;
        case X86EMUL_EXCEPTION:
            printk("X86EMUL_EXCEPTION\n");
            if ( ctxt.exn_pending )
                hvm_inject_exception(ctxt.exn_vector, ctxt.exn_error_code, 0);
            /* fall through */
        default:
            printk("default[%d]\n", rc);
            hvm_emulate_writeback(&ctxt);
            break;
    }
}

But after intercept some pairs of sysenter/sysexit, the vm go to crash,

and I got the follow dmesg, what's wrong with it? thank you very much

#sudo xm dmesg 

(XEN) event_channel.c:250:d1 EVTCHNOP failure: error -17

(XEN) event_channel.c:250:d1 EVTCHNOP failure: error -17

(XEN) irq.c:1954: dom1: pirq 55 or emuirq 8 already mapped

(XEN) irq.c:1954: dom1: pirq 55 or emuirq 12 already mapped

(XEN) irq.c:1954: dom1: pirq 55 or emuirq 1 already mapped

(XEN) irq.c:1954: dom1: pirq 55 or emuirq 6 already mapped

(XEN) irq.c:1954: dom1: pirq 55 or emuirq 4 already mapped

(XEN) irq.c:1954: dom1: pirq 55 or emuirq 7 already mapped

(XEN) irq.c:1954: dom1: pirq 55 or emuirq 23 already mapped

(XEN) irq.c:1954: dom1: pirq 55 or emuirq 28 already mapped

> 
> > 
> >> (2)I want to iuntercept syscall/sysret, so I unset the EFER.SCE, so 
> >> syscall/sysret will trap into Xen, then I emulate syscall/sysret.
> >> But  I only see syscall and did not see one sysret,  the guest run as usual. 
> >>  any one can give me an hint?
> > 
> > Assuming you did everything correctly, this seems odd. But in any
> > event I'd suggest confirming such behavior in a native environment
> > first.
> > 
> > Jan
> > 
> 



--
Best Regards,
yandong

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