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 18:59 -0700 on 23 Jul (1374605957), Mukesh Rathor wrote:
> +/*
> + * Set vmcs fields in support of vcpu_op -> VCPUOP_initialise hcall.  Called
> + * from arch_set_info_guest() which sets the (PVH relevant) non-vmcs fields.
> + *
> + * In case of linux:
> + *     The boot vcpu calls this to set some context for the non boot smp 
> vcpu.
> + *     The call comes from cpu_initialize_context().  (boot vcpu 0 context is
> + *     set by the tools via do_domctl -> vcpu_initialise).
> + *
> + * NOTE: In case of VMCS, loading a selector doesn't cause the hidden fields
> + *       to be automatically loaded. We load selectors here but not the 
> hidden
> + *       parts, except for GS_BASE and FS_BASE. This means we require the
> + *       guest to have same hidden values as the default values loaded in the
> + *       vmcs in pvh_construct_vmcs(), ie, the GDT the vcpu is coming up on
> + *       should be something like following,
> + *       (from 64bit linux, CS:0x10 DS/SS:0x18) :
> + *
> + *           ffff88007f704000:  0000000000000000 00cf9b000000ffff
> + *           ffff88007f704010:  00af9b000000ffff 00cf93000000ffff
> + *           ffff88007f704020:  00cffb000000ffff 00cff3000000ffff

What a bizarre interface!  Why does this operation not load the hidden
parts from the GDT/LDT that the caller supplied?

If this _is_ to be the interface:
  - this comment should be somewhere in the interface headers (and docs)
    so that OS authors can find it; and
  - it should specify the _exact_ constraints that the guest must
    follow in constructing its tables.

Tim.


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