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

[Juergen Gross <jgross@xxxxxxxx>]

On 04.02.26 11:04, Jan Beulich wrote:
> On 04.02.2026 11:01, Juergen Gross wrote:
> > On 04.02.26 10:51, Jan Beulich wrote:
> > > On 04.02.2026 10:25, Juergen Gross wrote:
> > > > On 04.02.26 10:15, Jan Beulich wrote:
> > > > > On 04.02.2026 10:00, Roger Pau Monné wrote:
> > > > > > On Wed, Feb 04, 2026 at 08:56:10AM +0100, Jan Beulich wrote:
> > > > > > > On 04.02.2026 08:49, Roger Pau Monné wrote:
> > > > > > > > Also, I would remove the tools guards, I think once a DOMID_ constant
> > > > > > > > is allocated it becomes part of the public ABI, and it cannot be
> > > > > > > > withdrawn.  See for example DOMID_IDLE: it's only used internally in
> > > > > > > > the hypervisor AFAICT, yet the define is fully visible in the
> > > > > > > > headers.
> > > > > > > It was me to ask for it to be guarded like this. DOMID_IDLE (and perhaps
> > > > > > > others) not being guarded (at least for IDLE: by just __XEN__) imo was a
> > > > > > > mistake. That mistake may in fact be correctable, if we could prove that
> > > > > > > the ID cannot usefully be passed into anywhere.
> > > > > > Even if it's not passed into anything, does it make sense to guard
> > > > > > them?  The reserved domid values are already consumed, ie: cannot be
> > > > > > reused in any way.  It just seem to me like more ifdefery churn for no
> > > > > > specific benefit.
> > > > > Well. From an abstract perspective, purely hypothetical at this point, I
> > > > > could see a potential need to re-number them, e.g. to simplify checking
> > > > > against groups of these special IDs.
> > > > >
> > > > > Yes, excess #ifdef-ary is an issue. Excess exposure of things also is,
> > > > > though. Finding the right balance between both can be interesting.
> > > > I have a patch in work which would want DOMID_ANY not be guarded. I think
> > > > especially DOMID_ANY could be useful for other cases, too.
> > > Mind me asking where, outside of the toolstack, you intend to use it?
> > I'd like to be able to use it for Xenstore permissions.
> >
> > Primary use case would be to allow the special watches for domain creation
> > and removal to be usable for all guests, but there might be use cases where
> > a domU wants to give node read access for everyone.
> Would that require exposing beyond the toolstack's boundaries?
Yes, as this would require the user to specify DOMID_ANY as the domid in
struct xs_permissions.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature