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

[dmukhin@xxxxxxx]

On Tue, Sep 23, 2025 at 12:43:54AM +0200, Jan Beulich wrote:
> On 22.09.2025 23:56, dmukhin@xxxxxxx wrote:
> > On Mon, Sep 22, 2025 at 05:23:37PM +0200, Jan Beulich wrote:
> >> On 20.09.2025 19:47, dmukhin@xxxxxxx wrote:
> >>> From: Denis Mukhin <dmukhin@xxxxxxxx> 
> >>>
> >>> 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@xxxxxxxx>
> >>> ---
> >>> Changes since v1:
> >>> - moved DOMID_ANY from the public header
> >>
> >> This addresses my comment, but not Andrew's subsequent response, 
> >> specifically
> >> aiming at ...
> > 
> > AFAIU, toolstack should start using DOMID_ANY instead of 0 in
> > XEN_DOMCTL_createdomain.
> > 
> > I was planning to send a separate patch to address it if that's OK.
> > 
> >>
> >>> --- a/tools/tests/domid/harness.h
> >>> +++ b/tools/tests/domid/harness.h
> >>> @@ -41,6 +41,7 @@ extern unsigned long find_next_zero_bit(const unsigned 
> >>> long *addr,
> >>>  
> >>>  #define DOMID_FIRST_RESERVED            (100)
> >>>  #define DOMID_INVALID                   (101)
> >>> +#define DOMID_ANY                       DOMID_INVALID
> >>
> >> ... avoiding the need for any such secondary definitions.
> > 
> > In the current design, unit test harness.h has to define DOMID_ANY.
> > Enabling xen/domain.h to compile for unit test is a separate task, IMO.
> 
> That wasn't suggested as an option. The #define wants to move back to
> the public header, but be properly guarded there. See the v1 replies
> you got.

Got it, thanks.
Will send v3.