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 13:53, Tim Deegan <tim@xxxxxxx> wrote:
> At 12:04 +0100 on 12 Aug (1376309065), Jan Beulich wrote:
>> >>> 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.
> 
> Ah, you're right, that's explicilty disallowed. :(  Xen could set any
> non-null descriptor (still requiring the caller to specify null
> descriptors and documenting that the descriptor registers will be
> undefined until the guest loads them on the new vcpu).

Hmm, yes, I don't really like starting a guest with inconsistent state,
but it's an option.

> If we really require the selectors to match the GDT contents then we
> either have to constrain the selector/GDT contents (a horrible
> interface) or properly emulate the loads (which surely we already have
> code in Xen to do).

protmode_load_seg() in the x86 emulation code appears to be the
only one. But it doesn't seem impossible to leverage this here.

Jan


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