* Re: [PATCH v4] xen/domain: introduce DOMID_ANY
2026-01-09 14:07 [PATCH v4] xen/domain: introduce DOMID_ANY dmukhin
@ 2026-01-30 0:37 ` Stefano Stabellini
2026-01-30 6:14 ` Jürgen Groß
2026-02-04 7:49 ` Roger Pau Monné
2 siblings, 0 replies; 14+ messages in thread
From: Stefano Stabellini @ 2026-01-30 0:37 UTC (permalink / raw)
To: dmukhin
Cc: xen-devel, andrew.cooper3, anthony.perard, jbeulich, julien,
michal.orzel, roger.pau, sstabellini, dmukhin
On Fri, 9 Jan 2026, dmukhin@xen.org wrote:
> From: Denis Mukhin <dmukhin@ford.com>
>
> Add a new symbol DOMID_ANY 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@ford.com>
I think it improves readability and this new version addresses Roger's
concerns as far as I can tell.
One minor comment: domid_alloc effectively still accept DOMID_INVALID to
say "give me any DOMID" although it is no longer documented or used. If
we wanted to enforce a different behavior between DOMID_INVALID and
DOMID_ANY we would need to modify domid_alloc.
However, I think this patch is sufficient as it is:
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> Changes since v3:
> - new value for DOMID_ANY instead of aliasing DOMID_INVALID
> - Link to v3: https://lore.kernel.org/xen-devel/20250924030630.122229-2-dmukhin@ford.com/
> ---
> tools/tests/domid/harness.h | 1 +
> tools/tests/domid/test-domid.c | 12 ++++++------
> xen/common/device-tree/dom0less-build.c | 2 +-
> xen/common/domctl.c | 2 +-
> xen/common/domid.c | 2 +-
> xen/include/public/xen.h | 5 +++++
> 6 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/tools/tests/domid/harness.h b/tools/tests/domid/harness.h
> index 17eb22a9a854..65da0d075a2b 100644
> --- 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 (102)
>
> #endif /* _TEST_HARNESS_ */
>
> diff --git a/tools/tests/domid/test-domid.c b/tools/tests/domid/test-domid.c
> index 5915c4699a5c..71cc4e7fd86d 100644
> --- a/tools/tests/domid/test-domid.c
> +++ b/tools/tests/domid/test-domid.c
> @@ -41,20 +41,20 @@ int main(int argc, char **argv)
> domid_free(expected);
>
> /*
> - * Test that that two consecutive calls of domid_alloc(DOMID_INVALID)
> + * Test that that two consecutive calls of domid_alloc(DOMID_ANY)
> * will never return the same ID.
> * NB: ID#0 is reserved and shall not be allocated by
> - * domid_alloc(DOMID_INVALID).
> + * domid_alloc(DOMID_ANY).
> */
> for ( expected = 1; expected < DOMID_FIRST_RESERVED; expected++ )
> {
> - allocated = domid_alloc(DOMID_INVALID);
> + allocated = domid_alloc(DOMID_ANY);
> verify(allocated == expected,
> "TEST 3: expected %u allocated %u\n", expected, allocated);
> }
> for ( expected = 1; expected < DOMID_FIRST_RESERVED; expected++ )
> {
> - allocated = domid_alloc(DOMID_INVALID);
> + allocated = domid_alloc(DOMID_ANY);
> verify(allocated == DOMID_INVALID,
> "TEST 4: expected %u allocated %u\n", DOMID_INVALID, allocated);
> }
> @@ -64,7 +64,7 @@ int main(int argc, char **argv)
> domid_free(expected);
> for ( expected = 1; expected < DOMID_FIRST_RESERVED / 2; expected++ )
> {
> - allocated = domid_alloc(DOMID_INVALID);
> + allocated = domid_alloc(DOMID_ANY);
> verify(allocated == expected,
> "TEST 5: expected %u allocated %u\n", expected, allocated);
> }
> @@ -72,7 +72,7 @@ int main(int argc, char **argv)
> /* Re-allocate last ID from [1..DOMID_FIRST_RESERVED - 1]. */
> expected = DOMID_FIRST_RESERVED - 1;
> domid_free(DOMID_FIRST_RESERVED - 1);
> - allocated = domid_alloc(DOMID_INVALID);
> + allocated = domid_alloc(DOMID_ANY);
> verify(allocated == expected,
> "TEST 6: expected %u allocated %u\n", expected, allocated);
>
> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
> index 495ef7b16aa0..9130c38681df 100644
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -842,7 +842,7 @@ void __init create_domUs(void)
> if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED )
> panic("No more domain IDs available\n");
>
> - domid = domid_alloc(DOMID_INVALID);
> + domid = domid_alloc(DOMID_ANY);
> if ( domid == DOMID_INVALID )
> panic("Error allocating ID for domain %s\n", dt_node_name(node));
>
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index 29a7726d32d0..e2c8990531ad 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -410,7 +410,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> case XEN_DOMCTL_createdomain:
> {
> /* NB: ID#0 is reserved, find the first suitable ID instead. */
> - domid_t domid = domid_alloc(op->domain ?: DOMID_INVALID);
> + domid_t domid = domid_alloc(op->domain ?: DOMID_ANY);
>
> if ( domid == DOMID_INVALID )
> {
> diff --git a/xen/common/domid.c b/xen/common/domid.c
> index 2387ddb08300..76b7f3e7ae6e 100644
> --- a/xen/common/domid.c
> +++ b/xen/common/domid.c
> @@ -19,7 +19,7 @@ static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
> * @param domid Domain ID hint:
> * - If an explicit domain ID is provided, verify its availability and use it
> * if ID is not used;
> - * - If DOMID_INVALID is provided, search [1..DOMID_FIRST_RESERVED-1] range,
> + * - If DOMID_ANY is provided, search [1..DOMID_FIRST_RESERVED-1] range,
> * starting from the last used ID. Implementation guarantees that two
> * consecutive calls will never return the same ID. ID#0 is reserved for
> * the first boot domain (currently, dom0) and excluded from the allocation
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 7f15204c3885..b5789c32ae1f 100644
> --- 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
> +
> /* Idle domain. */
> #define DOMID_IDLE xen_mk_uint(0x7FFF)
>
> --
> 2.52.0
>
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH v4] xen/domain: introduce DOMID_ANY
2026-01-09 14:07 [PATCH v4] xen/domain: introduce DOMID_ANY dmukhin
2026-01-30 0:37 ` Stefano Stabellini
@ 2026-01-30 6:14 ` Jürgen Groß
2026-02-04 7:49 ` Roger Pau Monné
2 siblings, 0 replies; 14+ messages in thread
From: Jürgen Groß @ 2026-01-30 6:14 UTC (permalink / raw)
To: dmukhin, xen-devel
Cc: andrew.cooper3, anthony.perard, jbeulich, julien, michal.orzel,
roger.pau, sstabellini, dmukhin
[-- Attachment #1.1.1: Type: text/plain, Size: 565 bytes --]
On 09.01.26 15:07, dmukhin@xen.org wrote:
> From: Denis Mukhin <dmukhin@ford.com>
>
> Add a new symbol DOMID_ANY 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@ford.com>
I'm really happy you wrote this patch, as I'm working on a series for
xenstored, where I need DOMID_ANY. I was just about to introduce something
like that myself. :-)
Reviewed-by: Juergen Gross <jgross@suse.com>
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH v4] xen/domain: introduce DOMID_ANY
2026-01-09 14:07 [PATCH v4] xen/domain: introduce DOMID_ANY dmukhin
2026-01-30 0:37 ` Stefano Stabellini
2026-01-30 6:14 ` Jürgen Groß
@ 2026-02-04 7:49 ` Roger Pau Monné
2026-02-04 7:56 ` Jan Beulich
2 siblings, 1 reply; 14+ messages in thread
From: Roger Pau Monné @ 2026-02-04 7:49 UTC (permalink / raw)
To: dmukhin
Cc: xen-devel, andrew.cooper3, anthony.perard, jbeulich, julien,
michal.orzel, sstabellini, dmukhin
On Fri, Jan 09, 2026 at 06:07:48AM -0800, dmukhin@xen.org wrote:
> From: Denis Mukhin <dmukhin@ford.com>
>
> Add a new symbol DOMID_ANY 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@ford.com>
> ---
> Changes since v3:
> - new value for DOMID_ANY instead of aliasing DOMID_INVALID
> - Link to v3: https://lore.kernel.org/xen-devel/20250924030630.122229-2-dmukhin@ford.com/
> ---
> tools/tests/domid/harness.h | 1 +
> tools/tests/domid/test-domid.c | 12 ++++++------
> xen/common/device-tree/dom0less-build.c | 2 +-
> xen/common/domctl.c | 2 +-
> xen/common/domid.c | 2 +-
> xen/include/public/xen.h | 5 +++++
> 6 files changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/tools/tests/domid/harness.h b/tools/tests/domid/harness.h
> index 17eb22a9a854..65da0d075a2b 100644
> --- 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 (102)
>
> #endif /* _TEST_HARNESS_ */
>
> diff --git a/tools/tests/domid/test-domid.c b/tools/tests/domid/test-domid.c
> index 5915c4699a5c..71cc4e7fd86d 100644
> --- a/tools/tests/domid/test-domid.c
> +++ b/tools/tests/domid/test-domid.c
> @@ -41,20 +41,20 @@ int main(int argc, char **argv)
> domid_free(expected);
>
> /*
> - * Test that that two consecutive calls of domid_alloc(DOMID_INVALID)
> + * Test that that two consecutive calls of domid_alloc(DOMID_ANY)
> * will never return the same ID.
> * NB: ID#0 is reserved and shall not be allocated by
> - * domid_alloc(DOMID_INVALID).
> + * domid_alloc(DOMID_ANY).
> */
> for ( expected = 1; expected < DOMID_FIRST_RESERVED; expected++ )
> {
> - allocated = domid_alloc(DOMID_INVALID);
> + allocated = domid_alloc(DOMID_ANY);
> verify(allocated == expected,
> "TEST 3: expected %u allocated %u\n", expected, allocated);
> }
> for ( expected = 1; expected < DOMID_FIRST_RESERVED; expected++ )
> {
> - allocated = domid_alloc(DOMID_INVALID);
> + allocated = domid_alloc(DOMID_ANY);
> verify(allocated == DOMID_INVALID,
> "TEST 4: expected %u allocated %u\n", DOMID_INVALID, allocated);
> }
> @@ -64,7 +64,7 @@ int main(int argc, char **argv)
> domid_free(expected);
> for ( expected = 1; expected < DOMID_FIRST_RESERVED / 2; expected++ )
> {
> - allocated = domid_alloc(DOMID_INVALID);
> + allocated = domid_alloc(DOMID_ANY);
> verify(allocated == expected,
> "TEST 5: expected %u allocated %u\n", expected, allocated);
> }
> @@ -72,7 +72,7 @@ int main(int argc, char **argv)
> /* Re-allocate last ID from [1..DOMID_FIRST_RESERVED - 1]. */
> expected = DOMID_FIRST_RESERVED - 1;
> domid_free(DOMID_FIRST_RESERVED - 1);
> - allocated = domid_alloc(DOMID_INVALID);
> + allocated = domid_alloc(DOMID_ANY);
> verify(allocated == expected,
> "TEST 6: expected %u allocated %u\n", expected, allocated);
>
> diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c
> index 495ef7b16aa0..9130c38681df 100644
> --- a/xen/common/device-tree/dom0less-build.c
> +++ b/xen/common/device-tree/dom0less-build.c
> @@ -842,7 +842,7 @@ void __init create_domUs(void)
> if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED )
> panic("No more domain IDs available\n");
>
> - domid = domid_alloc(DOMID_INVALID);
> + domid = domid_alloc(DOMID_ANY);
> if ( domid == DOMID_INVALID )
> panic("Error allocating ID for domain %s\n", dt_node_name(node));
>
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index 29a7726d32d0..e2c8990531ad 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -410,7 +410,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> case XEN_DOMCTL_createdomain:
> {
> /* NB: ID#0 is reserved, find the first suitable ID instead. */
> - domid_t domid = domid_alloc(op->domain ?: DOMID_INVALID);
> + domid_t domid = domid_alloc(op->domain ?: DOMID_ANY);
I don't think you need to do it here, but you want to check the
parameter passed to domid_alloc(). It should return an error if:
domid >= DOMID_FIRST_RESERVED && domid != DOMID_ANY
>
> if ( domid == DOMID_INVALID )
> {
> diff --git a/xen/common/domid.c b/xen/common/domid.c
> index 2387ddb08300..76b7f3e7ae6e 100644
> --- a/xen/common/domid.c
> +++ b/xen/common/domid.c
> @@ -19,7 +19,7 @@ static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED);
> * @param domid Domain ID hint:
> * - If an explicit domain ID is provided, verify its availability and use it
> * if ID is not used;
> - * - If DOMID_INVALID is provided, search [1..DOMID_FIRST_RESERVED-1] range,
> + * - If DOMID_ANY is provided, search [1..DOMID_FIRST_RESERVED-1] range,
> * starting from the last used ID. Implementation guarantees that two
> * consecutive calls will never return the same ID. ID#0 is reserved for
> * the first boot domain (currently, dom0) and excluded from the allocation
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 7f15204c3885..b5789c32ae1f 100644
> --- 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."
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.
Thanks, Roger.
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH v4] xen/domain: introduce DOMID_ANY
2026-02-04 7:49 ` Roger Pau Monné
@ 2026-02-04 7:56 ` Jan Beulich
2026-02-04 9:00 ` Roger Pau Monné
0 siblings, 1 reply; 14+ messages in thread
From: Jan Beulich @ 2026-02-04 7:56 UTC (permalink / raw)
To: Roger Pau Monné, dmukhin
Cc: xen-devel, andrew.cooper3, anthony.perard, julien, michal.orzel,
sstabellini, dmukhin
On 04.02.2026 08:49, Roger Pau Monné wrote:
> On Fri, Jan 09, 2026 at 06:07:48AM -0800, dmukhin@xen.org 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.
Jan
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v4] xen/domain: introduce DOMID_ANY
2026-02-04 7:56 ` Jan Beulich
@ 2026-02-04 9:00 ` Roger Pau Monné
2026-02-04 9:15 ` Jan Beulich
0 siblings, 1 reply; 14+ messages in thread
From: Roger Pau Monné @ 2026-02-04 9:00 UTC (permalink / raw)
To: Jan Beulich
Cc: dmukhin, xen-devel, andrew.cooper3, anthony.perard, julien,
michal.orzel, sstabellini, dmukhin
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, dmukhin@xen.org 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v4] xen/domain: introduce DOMID_ANY
2026-02-04 9:00 ` Roger Pau Monné
@ 2026-02-04 9:15 ` Jan Beulich
2026-02-04 9:25 ` Juergen Gross
0 siblings, 1 reply; 14+ messages in thread
From: Jan Beulich @ 2026-02-04 9:15 UTC (permalink / raw)
To: Roger Pau Monné
Cc: dmukhin, xen-devel, andrew.cooper3, anthony.perard, julien,
michal.orzel, sstabellini, dmukhin
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.
Jan
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v4] xen/domain: introduce DOMID_ANY
2026-02-04 9:15 ` Jan Beulich
@ 2026-02-04 9:25 ` Juergen Gross
2026-02-04 9:51 ` Jan Beulich
0 siblings, 1 reply; 14+ messages in thread
From: Juergen Gross @ 2026-02-04 9:25 UTC (permalink / raw)
To: Jan Beulich, Roger Pau Monné
Cc: dmukhin, xen-devel, andrew.cooper3, anthony.perard, julien,
michal.orzel, sstabellini, dmukhin
[-- Attachment #1.1.1: Type: text/plain, Size: 1707 bytes --]
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.
Look e.g. at XEN_ARGO_DOMID_ANY. Even if I don't think we can switch it
to DOMID_ANY, it shows that the concept as such is not restricted to Xen
internal use cases.
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v4] xen/domain: introduce DOMID_ANY
2026-02-04 9:25 ` Juergen Gross
@ 2026-02-04 9:51 ` Jan Beulich
2026-02-04 10:01 ` Juergen Gross
0 siblings, 1 reply; 14+ messages in thread
From: Jan Beulich @ 2026-02-04 9:51 UTC (permalink / raw)
To: Juergen Gross
Cc: dmukhin, xen-devel, andrew.cooper3, anthony.perard, julien,
michal.orzel, sstabellini, dmukhin, Roger Pau Monné
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? Note
that unlike IDLE and perhaps a few others, ...
> Look e.g. at XEN_ARGO_DOMID_ANY. Even if I don't think we can switch it
> to DOMID_ANY, it shows that the concept as such is not restricted to Xen
> internal use cases.
... I don't mean ANY to be constrained to just the hypervisor. That more
strict guarding came up only because of Roger mentioning IDLE.
Jan
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v4] xen/domain: introduce DOMID_ANY
2026-02-04 9:51 ` Jan Beulich
@ 2026-02-04 10:01 ` Juergen Gross
2026-02-04 10:04 ` Jan Beulich
0 siblings, 1 reply; 14+ messages in thread
From: Juergen Gross @ 2026-02-04 10:01 UTC (permalink / raw)
To: Jan Beulich
Cc: dmukhin, xen-devel, andrew.cooper3, anthony.perard, julien,
michal.orzel, sstabellini, dmukhin, Roger Pau Monné
[-- Attachment #1.1.1: Type: text/plain, Size: 2024 bytes --]
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.
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v4] xen/domain: introduce DOMID_ANY
2026-02-04 10:01 ` Juergen Gross
@ 2026-02-04 10:04 ` Jan Beulich
2026-02-04 10:12 ` Juergen Gross
0 siblings, 1 reply; 14+ messages in thread
From: Jan Beulich @ 2026-02-04 10:04 UTC (permalink / raw)
To: Juergen Gross
Cc: dmukhin, xen-devel, andrew.cooper3, anthony.perard, julien,
michal.orzel, sstabellini, dmukhin, Roger Pau Monné
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v4] xen/domain: introduce DOMID_ANY
2026-02-04 10:04 ` Jan Beulich
@ 2026-02-04 10:12 ` Juergen Gross
2026-02-04 10:15 ` Jan Beulich
0 siblings, 1 reply; 14+ messages in thread
From: Juergen Gross @ 2026-02-04 10:12 UTC (permalink / raw)
To: Jan Beulich
Cc: dmukhin, xen-devel, andrew.cooper3, anthony.perard, julien,
michal.orzel, sstabellini, dmukhin, Roger Pau Monné
[-- Attachment #1.1.1: Type: text/plain, Size: 2362 bytes --]
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 #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v4] xen/domain: introduce DOMID_ANY
2026-02-04 10:12 ` Juergen Gross
@ 2026-02-04 10:15 ` Jan Beulich
2026-02-04 10:26 ` Jürgen Groß
0 siblings, 1 reply; 14+ messages in thread
From: Jan Beulich @ 2026-02-04 10:15 UTC (permalink / raw)
To: Juergen Gross
Cc: dmukhin, xen-devel, andrew.cooper3, anthony.perard, julien,
michal.orzel, sstabellini, dmukhin, Roger Pau Monné
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v4] xen/domain: introduce DOMID_ANY
2026-02-04 10:15 ` Jan Beulich
@ 2026-02-04 10:26 ` Jürgen Groß
0 siblings, 0 replies; 14+ messages in thread
From: Jürgen Groß @ 2026-02-04 10:26 UTC (permalink / raw)
To: Jan Beulich
Cc: dmukhin, xen-devel, andrew.cooper3, anthony.perard, julien,
michal.orzel, sstabellini, dmukhin, Roger Pau Monné
[-- Attachment #1.1.1: Type: text/plain, Size: 2896 bytes --]
On 04.02.26 11:15, Jan Beulich wrote:
> 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.
Currently most library header files #include one or more Xen public headers.
xenstore.h e.g. already depends on xen/public/io/xs_wire.h.
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread