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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.08.13 at 12:24, Tim Deegan <tim@xxxxxxx> wrote:
> 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?

I don't think CS = null is valid. And similarly, for future 32-bit PVH
SS = null wouldn't be valid, and DS = null as well as ES = null would
likely be a bad idea there.

Jan


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