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: Mon, 15 Jul 2013 19:00:01 -0700
Message-ID: <20130715190001.3b31e06e@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>
	<20130627192818.2ba03853@mantra.us.oracle.com>
	<51CD770802000078000E1806@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: <51CD770802000078000E1806@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 Fri, 28 Jun 2013 10:44:08 +0100
"Jan Beulich" <JBeulich@suse.com> wrote:

> >>> On 28.06.13 at 04:28, Mukesh Rathor <mukesh.rathor@oracle.com>
> >>> wrote:
> > On Tue, 25 Jun 2013 11:49:57 +0100 "Jan Beulich"
> > <JBeulich@suse.com> wrote:
> >> > +int vmx_pvh_set_vcpu_info(struct vcpu *v, struct
> >> > vcpu_guest_context *ctxtp) +{
> >> > +    if ( v->vcpu_id == 0 )
> >> > +        return 0;
> >> > +
> >> > +    vmx_vmcs_enter(v);
> >> > +    __vmwrite(GUEST_GDTR_BASE, ctxtp->gdt.pvh.addr);
> >> > +    __vmwrite(GUEST_GDTR_LIMIT, ctxtp->gdt.pvh.limit);
> >> > +    __vmwrite(GUEST_GS_BASE, ctxtp->gs_base_user);
> >> > +
> >> > +    __vmwrite(GUEST_CS_SELECTOR, ctxtp->user_regs.cs);
> >> > +    __vmwrite(GUEST_DS_SELECTOR, ctxtp->user_regs.ds);
> >> > +    __vmwrite(GUEST_ES_SELECTOR, ctxtp->user_regs.es);
> >> > +    __vmwrite(GUEST_SS_SELECTOR, ctxtp->user_regs.ss);
> >> > +    __vmwrite(GUEST_GS_SELECTOR, ctxtp->user_regs.gs);
> >> 
> >> How does this work without also writing the "hidden" register
> >> fields?
> > 
> > This is for bringing up SMP CPUs by the guest, which already has
> > set GDT up so it just needs selectors to be loaded to start the
> > target vcpu.
> 
> That makes no sense to me: Once you VMLAUNCH that vCPU, it'll
> get the hidden register fields loaded from the VMCS, without
> accessing the GDT. If that understanding of mine is wrong, please
> explain how you see things working in more detail.

Re-reading this I realize I misunderstood your question. Sorry. The hidden
fields are set to the default values in vmcs create. That call comes from
the tool stack during domain creation via the do_domctl ---> vcpu_initialise
hcall. That happens during guest creation. Here, the guest is booting and 
bringing up secondary CPU, and wants to set certain fields via 
the do_vcpu_op() -> VCPUOP_initialise hcall.

Hope that clarifies.

Thanks
Mukesh