On Wed, Feb 04, 2026 at 08:56:10AM +0100, Jan Beulich wrote: > On 04.02.2026 08:49, Roger Pau Monné wrote: > > On Fri, Jan 09, 2026 at 06:07:48AM -0800, [email protected] wrote: > >> --- a/xen/include/public/xen.h > >> +++ b/xen/include/public/xen.h > >> @@ -608,6 +608,11 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t); > >> /* DOMID_INVALID is used to identify pages with unknown owner. */ > >> #define DOMID_INVALID xen_mk_uint(0x7FF4) > >> > >> +#if defined(__XEN__) || defined(__XEN_TOOLS__) > >> +/* Domain ID allocator: search [1..DOMID_FIRST_RESERVED-1] range. */ > >> +#define DOMID_ANY xen_mk_uint(0x7FF5) > >> +#endif > > > > I would attempt to word the comment in a more generic way. While this > > is now only used for the domain ID allocator, it's likely to gain more > > uses going forward (Juergen already expressed interest): > > > > "DOMID_ANY is used to signal no specific domid requested. Handler > > should pick a valid domid, or handle it as a broadcast value depending > > on the context." > > +1 > > > 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. Thanks, Roger.
