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

Re: [Xen-devel] [PATCH 18/18] PVH xen: introduce vmx_pvh.c



On Tue, 25 Jun 2013 11:49:57 +0100
"Jan Beulich" <JBeulich@xxxxxxxx> wrote:

> >>> On 25.06.13 at 02:01, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
> >>> wrote:
> > --- /dev/null
........
> > +void vmx_pvh_vmexit_handler(struct cpu_user_regs *regs)
> > +{
> > +    unsigned long exit_qualification;
> > +    unsigned int exit_reason = __vmread(VM_EXIT_REASON);
> > +    int rc=0, ccpu = smp_processor_id();
> > +    struct vcpu *v = current;
> > +
> > +    dbgp1("PVH:[%d]left VMCS exitreas:%d RIP:%lx RSP:%lx
> > EFLAGS:%lx CR0:%lx\n",
> > +          ccpu, exit_reason, regs->rip, regs->rsp, regs->rflags,
> > +          __vmread(GUEST_CR0));
> > +
> > +    /* For guest_kernel_mode which is called from most places
> > below. */
> > +    regs->cs = __vmread(GUEST_CS_SELECTOR);
> 
> Which raises the question of whether your uses of
> guest_kernel_mode() are appropriate in the first place: Before this
> series there's no use at all under xen/arch/x86/hvm/.
> 
> And if it is, I'd like to point out once again that this check should
> be looking at SS.DPL, not CS.RPL.

Are you suggesting changing the macro to check for SS.DPL instead of
CS.RPL it has always done for PV also? Note, PVH has checks in this
patch to enforce long mode execution always, so CS.RPL should always
be valid for PVH.

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