[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |