Re: [Xen-devel] [V10 PATCH 09/23] PVH xen: introduce pvh_set_vcpu_info() and vmx_pvh_set_vcpu_info()

[Tim Deegan <tim@xxxxxxx>]

At 08:54 +0100 on 12 Aug (1376297674), Jan Beulich wrote:
> >>> On 10.08.13 at 01:41, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> > Since we are loading gdtr and selectors cs/ds/ss, we should also load
> > the hidden fields for cs/ds/ss. That IMO is plenty enough support for
> > the vcpu to come up, and the vcpu itself can then load ldtr, fs base, gs
> > base, etc first thing in it's HVM container. What do you all think?
> 
> If you implement loading the hidden fields of CS, then doing the
> same for the LDT shouldn't be that much more code (and if you
> permit a non-null LDT selector, then having it in place would even
> be a requirement before validating the CS selector). But again,
> I had already indicated that I'd be fine with requiring the state to
> be truly minimal: CS -> flat 64-bit code descriptor, SS, DS, ES, FS
> and GS holding null selectors. And CS descriptor validation done
> only in debug mode.

If you're going that way, please go the whole hog:
 - _all_ of cs/ss/ds/es/fs/gs arguments required to be null
   (and so documented, and enforced).
 - GDT base/limit loaded from the args.
 - LDT base/limit args required (documented, enforced) to be zero.
 - Guest launches with a flat 32/64bit segments set up in the
   hidden part of all segments (or I guess on 32-bit you could have all
   but CS invalid).  Then it can load its real segment state after boot.

That way we don't have the weird constraints on the layout/contents
of the guest's GDT or on its segment descriptors.

Would that be OK?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel