Re: [Xen-devel] [PATCH v3 12/12] xen/domain: Allocate d->vcpu[] in domain_create()

[Juergen Gross <jgross@xxxxxxxx>]

On 31/08/18 12:57, Julien Grall wrote:
> (+ Juergen)
> 
> On 08/31/2018 11:42 AM, Jan Beulich wrote:
>>>>> On 31.08.18 at 12:33, <wei.liu2@xxxxxxxxxx> wrote:
>>> On Wed, Aug 29, 2018 at 09:03:36AM -0600, Jan Beulich wrote:
>>>>>>> On 29.08.18 at 16:40, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>> For ARM, the call to arch_domain_create() needs to have completed
>>>>> before
>>>>> domain_max_vcpus() will return the correct upper bound.
>>>>>
>>>>> For each arch's dom0's, drop the temporary max_vcpus parameter, and
>>>>> allocation
>>>>> of dom0->vcpu.
>>>>>
>>>>> With d->max_vcpus now correctly configured before evtchn_init(),
>>>>> the poll mask
>>>>> can be constructed suitably for the domain, rather than for the
>>>>> worst-case
>>>>> setting.
>>>>>
>>>>> Due to the evtchn_init() fixes, it no longer calls
>>>>> domain_max_vcpus(), and
>>>>> ARM's two implementations of vgic_max_vcpus() no longer need work
>>>>> around the
>>>>> out-of-order call.
>>>>>
>>>>>  From this point on, d->max_vcpus and d->vcpus[] are valid for any
>>>>> domain which
>>>>> can be looked up by domid.
>>>>>
>>>>> The XEN_DOMCTL_max_vcpus hypercall is modified to reject any call
>>>>> attempt with
>>>>> max != d->max_vcpus, which does match the older semantics (not that
>>>>> it is
>>>>> obvious from the code).  The logic to allocate d->vcpu[] is
>>>>> dropped, but at
>>>>> this point the hypercall still needs making to allocate each vcpu.
>>>>>
>>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>>
>>>> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>> in principle, but as said before the lack of renaming of the domctl
>>>> makes my ack dependent upon some other REST maintainer
>>>> agreeing with your position there (the more that you've added
>>>> the comment to the implementation rather than the public header).
>>>
>>> I don't see much value in renaming something that is due to be removed
>>> soon.
>>
>> I would agree if "soon" meant "soon" for sure. But we all know how things
>> get delayed. What I'd like to avoid is shipping 4.12 with a mis-named
>> domctl.
> 
> But that would be a waste of our time today if the DOMCTL is actually
> removed by Xen 4.12.
> 
> Can we delay the renaming until 4.12 freeze? If the removal does not
> make it, then we can discuss whether we want to rename the DOMCTL.
> 
> I guess the Juergen could track and remind us around the code freeze?

I'm fine with that.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel