From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mukesh Rathor <mukesh.rathor@oracle.com>
Subject: Re: [PATCH 18/18] PVH xen: introduce vmx_pvh.c
Date: Thu, 27 Jun 2013 18:35:01 -0700
Message-ID: <20130627183501.25bafddd@mantra.us.oracle.com>
References: <1372118507-16864-1-git-send-email-mukesh.rathor@oracle.com>
	<1372118507-16864-19-git-send-email-mukesh.rathor@oracle.com>
	<51C991F502000078000E04E5@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <51C991F502000078000E04E5@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

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

> >>> On 25.06.13 at 02:01, Mukesh Rathor <mukesh.rathor@oracle.com>
> >>> 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