Re: [PATCH v3] xen/domain: introduce DOMID_ANY

[dmukhin@xen.org]

On Wed, Dec 10, 2025 at 10:56:50AM +0100, Roger Pau Monné wrote:
> On Wed, Dec 10, 2025 at 08:36:37AM +0100, Jan Beulich wrote:
> > On 10.12.2025 02:04, Stefano Stabellini wrote:
> > > On Tue, 23 Sep 2025, dmukhin@xen.org wrote:
> > >> From: Denis Mukhin <dmukhin@ford.com> 
> > >>
> > >> Add a new symbol DOMID_ANY aliasing DOMID_INVALID to improve the readability
> > >> of the code.
> > >>
> > >> Update all relevant domid_alloc() call sites.
> > >>
> > >> Amends: 2d5065060710 ("xen/domain: unify domain ID allocation")
> > >> Signed-off-by: Denis Mukhin <dmukhin@ford.com>
> > > 
> > > Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> > 
> > The other day concern was voiced over aliasing DOMID_ANY with DOMID_INVALID.
> > I don't recall though who it was or where.
> 
> I'm afraid it was me (at least) that voiced such concern.  But then I
> completely forgot to reply to the patch.  I don't think this is a good
> idea, aliasing DOMID_ANY with DOMID_INVALID is likely to be dangerous
> in the long run.  In the example here it's fine, because the function
> itself doesn't use DOMID_INVALID (iow: all usages of DOMID_INVALID are
> replaced with DOMID_ANY).
> 
> However I could see a function wanting to use both DOMID_INVALID and
> DOMID_ANY for different purposes.  Having both aliased to the same
> value is not going to work as expected.  If we have to introduce
> DOMID_ANY it must use a different value than DOMID_INVALID.  And given
> the context here I would be fine leaving domid_alloc() to handle
> getting passed DOMID_INVALID as a signal to search for an empty domid
> to use, I don't see a compelling reason to introduce DOMID_ANY.

Thanks for the feedback!

I agree with having a dedicated reservation for DOMID_ANY.
I think introducing a new DOMID_ANY symbol improves code readability
a bit.

> 
> Thanks, Roger.