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.l...@citrix.com> wrote: >>> On Wed, Aug 29, 2018 at 09:03:36AM -0600, Jan Beulich wrote: >>>>>>> On 29.08.18 at 16:40, <andrew.coop...@citrix.com> 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.coop...@citrix.com> >>>> >>>> Acked-by: Jan Beulich <jbeul...@suse.com> >>>> 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
