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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 04.02.2026 11:12, Juergen Gross wrote:
> 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.

Hmm, I see. I wonder though whether things like this wouldn't want a separate
layer of abstraction, such that users of the library won't need to include
(and hence have available) Xen's public headers.

Jan