|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v8 17/21] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs
>>> 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).
>>> +int arch_initialize_vcpu(struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
>>> +{
>>> + struct domain *d = v->domain;
>>> + int rc;
>>> +
>>> + if ( is_hvm_vcpu(v) )
>>> + {
>>> + struct vcpu_hvm_context ctxt;
>>> +
>>> + if ( copy_from_guest(&ctxt, arg, 1) )
>>> + return -EFAULT;
>>> +
>>> + domain_lock(d);
>>> + rc = v->is_initialised ? -EEXIST : arch_set_info_hvm_guest(v,
>>> &ctxt);
>>> + domain_unlock(d);
>>> + }
>>> + else
>>> + {
>>> + struct vcpu_guest_context *ctxt;
>>> +
>>> + if ( (ctxt = alloc_vcpu_guest_context()) == NULL )
>>> + return -ENOMEM;
>>> +
>>> + if ( copy_from_guest(ctxt, arg, 1) )
>>> + {
>>> + free_vcpu_guest_context(ctxt);
>>> + return -EFAULT;
>>> + }
>>> +
>>> + domain_lock(d);
>>> + rc = v->is_initialised ? -EEXIST : arch_set_info_guest(v, ctxt);
>>> + domain_unlock(d);
>>> +
>>> + free_vcpu_guest_context(ctxt);
>>> + }
>>
>> This else branch looks suspiciously like the ARM variant, and iirc I
>> had asked already on an earlier version to have this handled in
>> common code (with ARM simply using the common function for its
>> arch_initialize_vcpu()).
>
> Done, I've created a default_initalize_vcpu that's shared between ARM
> and x86 PV guests. The arch_initialize_vcpu implementation on ARM is
> just a stub that calls default_initialize_vcpu.
I'd actually have expected that to just be a #define, but okay.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |