Re: [Xen-devel] [PATCH for-next] x86/pv: Factor out the calculation of LDT/GDT descriptor pointers

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 26/10/17 16:06, Jan Beulich wrote:
>>>> On 17.10.17 at 17:05, <andrew.cooper3@xxxxxxxxxx> wrote:
>> @@ -16,4 +17,14 @@ static inline int pv_emul_is_mem_write(const struct 
>> x86_emulate_state *state,
>>                                                : X86EMUL_UNHANDLEABLE;
>>  }
>>  
>> +/* Return a pointer to the GDT/LDT descriptor referenced by sel. */
>> +static inline const struct desc_struct *gdt_ldt_desc_ptr(unsigned int sel)
> I guess returning a pointer to const here is on the assumption that
> you hope we would never have a need to fiddle with the descriptor?

PV guests only have a single method to alter the entries of exiting
descriptor tables, HYPERVISOR_update_descriptor(), and that is indexed
by machine address.

We don't even support updates via emulation, and I don't expect this to
change moving forwards.

Of course, we can drop the const if things do change in the future.

>
>> +{
>> +    const struct vcpu *curr = current;
>> +    const struct desc_struct *tbl = (void *)
>> +        ((sel & X86_XEC_TI) ? LDT_VIRT_START(curr) : GDT_VIRT_START(curr));
> While the two happen to match, using an error code related
> constant with something named "selector" doesn't look to be
> really correct. But given the match, I don't mind it being this
> way.
>
> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

Thanks.

As some point, I was thinking of moving some of my XTF x86 library into
Xen, and clean up the multiple/inconsistent definitions we have of
various architectural bits, but that is a job for a different day.

~Andrew

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