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

[Julien Grall <julien.grall@xxxxxxx>]

(+ 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?

Cheers,

--
Julien Grall

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