Re: [Xen-devel] [PATCH v8 17/21] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.11.15 at 10:47, <roger.pau@xxxxxxxxxx> wrote:
> El 27/11/15 a les 9.00, Jan Beulich ha escrit:
>>>>> On 26.11.15 at 17:57, <roger.pau@xxxxxxxxxx> wrote:
>>> El 12/11/15 a les 17.57, Jan Beulich ha escrit:
>>>>>>> On 06.11.15 at 17:05, <roger.pau@xxxxxxxxxx> wrote:
>>>>> +    if ( reg.attr.fields.pad != 0 )
>>>>> +    {
>>>>> +        gprintk(XENLOG_ERR,
>>>>> +                "Attribute bits 12-15 of the segment are not zero\n");
>>>>> +        return -EINVAL;
>>>>> +    }
>>>>> +
>>>>> +    if ( reg.sel == 0 && reg.base == 0 && reg.limit == 0 &&
>>>>
>>>> What's the sel check good for when your only caller only ever calls
>>>> you with it being zero?
>>>
>>> I don't mind removing the sel == 0 check but I don't think it hurts either.
>> 
>> Its presence having confused me means it may confuse other readers.
>> 
>>>> Looking at base or limit here doesn't seem
>>>> right either.
>>>
>>> I'm sorry but I'm not following you here, why is this not right? Would
>>> you rather conclude that the user is trying to load a null segment by
>>> just looking at the attributes field (and checking it's 0)?
>> 
>> Yes, exactly. Attributes being all zero makes a segment a null one
>> regardless of base or limit (if anything refusing non-zero base/limit
>> when attributes are zero as being inconsistent would be an option).
> 
> Thanks for the feedback, I'm also wondering whether I should call
> hvm_cr4_guest_reserved_bits and hvm_efer_valid like it's done in
> hvm_load_cpu_ctxt. Currently we don't perform any of the EFER/CR4 checks
> in order to make sure that what the user enables is actually allowed.
> What do you think?

Sounds like a good idea.

Jan


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