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

[Jan Beulich <jbeulich@xxxxxxxx>]

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?

Jan