[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] PVH: iopl



On Wed, 19 Sep 2012 12:29:07 -0700
Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:

> 
> I noticed anamoly in my code the way IOPL is set. For vcpu 0, its done
> via
> 
>         set_iopl.iopl = 1;
>       rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
> 
> in xen_start_kernel() in enlighten.c. But, for non boot vcpus, its
> done via eflags in cpu_initialize_context():
>         ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
> 
> Since I am running in HVM container, IO ops cause vmexit. I can just
> check eflags at that point for guest IOPL. So I am thinking of just
> using eflags and not doing the hcall.  It will also reduce the need
> for another field in the struct pv_vcpu for me. 
> 
> (JFYI: EXIT_REASON_IO_INSTRUCTION cause emulate_privileged_op() to be
> called).

So, I got rid of calling hcall to set iopl. The guest just manages
via eflags. Then upon vmexit:

{
    int curr_lvl;
    int requested = (regs->rflags >> 12) & 3;
    read_vmcs_selectors(regs);
    curr_lvl = regs->cs & 3;

    if (requested >= curr_lvl && emulate_privileged_op(regs))
        return success;

    hvm_inject_hw_exception(TRAP_gp_fault, regs->error_code);
}

I tested it out, and seems fine.

thanks,
Mukesh


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


 


Rackspace

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