Re: [Xen-devel] [PATCH 10/17] PVH xen: introduce vmx_pvh.c and pvh.c

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.05.13 at 03:25, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> On Mon, 06 May 2013 07:44:33 +0100
> "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>> >>> On 04.05.13 at 03:40, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
>> >>> wrote:
>> > On Fri, 03 May 2013 07:33:50 +0100 "Jan Beulich"
>  access rights, not the ones of the selector register you read.
>> > 
>> > Hmm... unless I'm reading the SDM wrong, it says "for non-code
>> > segments bit 21 is reserved and should always be set to 0". But its
>> > prob clearer to check for _CS_ only. 
>> 
>> I'm afraid you're still not understanding what I'm trying to explain:
>> Whether base and limit are ignored (and default to 0/~0) depends
>> on whether the guest executes in 64-bit mode, and this you can
>> know only by looking at CS.L, no matter what selector register
>> you're reading.
>> 
>> Maybe part of the confusion stems from you mixing two things
>> here - reading of a descriptor from a descriptor table (which is
>> what read_descriptor() does, as that's all you can do for PV
>> guests) vs reading of the hidden portions of a selector register
>> (which is what hvm_get_segment_register() does, thanks to
>> VMX/SVM providing access).
> 
> read_descriptor() confuses me a lot. The way I understood it: it reads
> the full desc from LDT/GDT indexed by the selector, which is where the 
> hidden 
> portions get loaded from, so it has full info like we get from vmcs.
> It can look at the "Type" bits 8-11 in the upper half and figure if it's
> code segment also.  Following check in it adds to confusiong:
> 
>         if ( !(vm86attr & _SEGMENT_CODE) )
>             desc.b &= ~_SEGMENT_L;

Not sure what's confusing about this - the L bit is meaningful only
in code segments.

> Anyways, I think (and hope), I finally have it:

Yes, looks like so (leaving aside a couple of casts I don't know
why you think you need).

Jan


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