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 26.07.13 at 02:58, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> On Thu, 25 Jul 2013 14:47:55 +0100
> Tim Deegan <tim@xxxxxxx> wrote:
> 
>> At 18:59 -0700 on 23 Jul (1374605957), Mukesh Rathor wrote:
> ....
>> > + * Set vmcs fields in support of vcpu_op -> VCPUOP_initialise
>> > hcall.  Called
>> > 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?
> 
> Pl see: http://lists.xen.org/archives/html/xen-devel/2013-07/msg01489.html 
> 
> That was an option discussed with Jan, walking and reading the GDT
> entries from the gdtaddr the guest provided to load the hidden
> parts. But, I agree with him, that for the initial cpu boot we can
> restrict the ABI to say: 0 base addr, ~0 limit, and "read/write,
> accessed" default attributes for the hidden part (64bit guest). 

That must be a misunderstanding then (also see my other reply) - I
always meant to require that you either properly load the hidden
register portions from the descriptor tables, or at least verify that
the descriptor table entries referenced match the defaults you
enforce.

Jan


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