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 13.08.13 at 02:27, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> On Mon, 12 Aug 2013 08:54:34 +0100 "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> It seems so unlikely that any guest would *require* LDT table set on
> boot, that I'll just check for NULL like you said above. We can always
> enhance in future. CS->flat is an option, but it would require special
> code in linux. It would be nice to keep that code same for both PV and
> PVH in linux.

Why would using a flat 64-bit CS require special code in Linux?
It's already running on a flat 64-bit CS...

>> Talking of the LDT selector: Iirc you modify struct
>> vcpu_guest_context's GDT to match PVH needs, but if I'm not
>> mistaken you don't do the same for the LDT - PVH would require
>> merely a selector here, not a base/ents pair.
> 
> I think that's way overkill, may make sense for PV, but PVH can
> just do it first thing in it's boot code.

If you think so, then you're not clear of the implications, including
that this - being part of the hypervisor/guest interface - needs to
be fixed _now_ rather than later. What I think you neglect here is
that struct vcpu_guest_context is also used for save/restore, and
there you _need_ to properly represent the LDT. So you have two
choices: Keep the structure the way it is and require the guest to
do LDT management the PV way (which will be very hard, as you
have no spare selectors to use for it), or do things the HVM way
(having the guest use the LDT instruction, implying that it's the
selector and nothing else that needs to be saved/restored).

If you go that latter, more natural route, then you next need to
(immediately) decide whether the extra context will also be save/
restored HVM-like (via struct hvm_hw_cpu), in which case the LDT
related fields mentioned above are just unused on the PVH case
(and you'd want to validate that they're zeroed).

Jan


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