From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [PATCH 18/18] PVH xen: introduce vmx_pvh.c Date: Tue, 16 Jul 2013 17:47:01 -0700 Message-ID: <20130716174701.01a724d5@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> <20130715190001.3b31e06e@mantra.us.oracle.com> <51E5096902000078000E5347@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51E5096902000078000E5347@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On Tue, 16 Jul 2013 07:50:49 +0100 "Jan Beulich" wrote: > >>> On 16.07.13 at 04:00, Mukesh Rathor > >>> wrote: > > On Fri, 28 Jun 2013 10:44:08 +0100 > > "Jan Beulich" wrote: > > > >> >>> On 28.06.13 at 04:28, Mukesh Rathor > >> >>> wrote: > >> > On Tue, 25 Jun 2013 11:49:57 +0100 "Jan Beulich" > >> > wrote: > >> >> > +int vmx_pvh_set_vcpu_info(struct vcpu *v, struct .... > >> >> 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. > > Yes, that clarifies that my complaint was right. Either you add a > comment to the code stating why you don't load these fields with > the guest specified values (from the GDT/LDT), or you set them > to the specified values rather than the defaults (or, of course, a > mixture of both - it may be reasonable to require the descriptors > referenced by CS, SS, DS, and ES to use defaults, but extending > this to FS, GS, and LDT would likely be too much of a requirement). > And even if implying defaults, verifying the descriptors to match > those requirements at least in debug builds may be a good idea. I see your point. I had it in the back of my mind that loading a selector will cause the hidden fields to be loaded, SDM Vol 3A 3.4.3, but I see that it doesn't apply to VMCS. I didn't realize this because the default values are the same as the initial guest GDT. So, options: o Add comment indicating that we don't need to load hidden parts because they are same as default values. - This makes it linux dependent. o Load hidden parts also for any non null CS/SS/DS/ES selector being loaded. - This is better if the guest GDT doesn't match defaults. o Don't worry about the selectors in xen, just let the guest load it itself first thing. I tested this and works fine. The ABI is flexible at this point :). Please lmk what you prefer. I prefer the last option as I believe the hypervisor should do the least, but am OK with any options you prefer. I think this is the last issue from prev version, and I'd be ready to submit next version of patches as soon as I fix this. thanks Mukesh