Re: [PATCH v17 0/4] xen/domain: domain ID allocation

[Alejandro Vallejo <alejandro.garciavallejo@amd.com>]

On Thu Sep 4, 2025 at 10:15 PM CEST, Demi Marie Obenour wrote:
> On 8/29/25 19:21, dmukhin@xen.org wrote:
>> Patch 1 introduces new domid_{alloc,free} calls.
>> Patch 2 is a prep change for domain ID allocator test.
>> Patch 3 introduces some basic testing for domain ID allocator.
>> Patch 4 adjusts create_dom0() messages (use %pd).
>> 
>> Link to v16: https://lore.kernel.org/xen-devel/20250812223024.2364749-1-dmukhin@ford.com/
>> Link to CI: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2012378054
>> 
>> Denis Mukhin (4):
>>   xen/domain: unify domain ID allocation
>>   tools/include: move xc_bitops.h to xen-tools/bitops.h
>>   tools/tests: introduce unit tests for domain ID allocator
>>   xen/domain: update create_dom0() messages
>> 
>>  .../xen-tools/bitops.h}                       | 16 +++-
>>  tools/libs/ctrl/xc_misc.c                     | 13 +--
>>  tools/libs/guest/xg_dom_elfloader.c           |  1 -
>>  tools/libs/guest/xg_dom_hvmloader.c           |  1 -
>>  tools/libs/guest/xg_private.h                 |  2 +-
>>  tools/libs/guest/xg_sr_common.h               |  2 -
>>  tools/tests/Makefile                          |  1 +
>>  tools/tests/domid/.gitignore                  |  2 +
>>  tools/tests/domid/Makefile                    | 88 +++++++++++++++++
>>  tools/tests/domid/harness.h                   | 54 +++++++++++
>>  tools/tests/domid/test-domid.c                | 95 +++++++++++++++++++
>>  xen/arch/arm/domain_build.c                   | 13 ++-
>>  xen/arch/x86/setup.c                          | 11 ++-
>>  xen/common/Makefile                           |  1 +
>>  xen/common/device-tree/dom0less-build.c       | 15 +--
>>  xen/common/domain.c                           |  2 +
>>  xen/common/domctl.c                           | 43 ++-------
>>  xen/common/domid.c                            | 95 +++++++++++++++++++
>>  xen/include/xen/domain.h                      |  3 +
>>  xen/lib/find-next-bit.c                       |  5 +
>>  20 files changed, 397 insertions(+), 66 deletions(-)
>>  rename tools/{libs/ctrl/xc_bitops.h => include/xen-tools/bitops.h} (84%)
>>  create mode 100644 tools/tests/domid/.gitignore
>>  create mode 100644 tools/tests/domid/Makefile
>>  create mode 100644 tools/tests/domid/harness.h
>>  create mode 100644 tools/tests/domid/test-domid.c
>>  create mode 100644 xen/common/domid.c
>
> Would it make sense to support virtualizing the domain ID space?
> That would allow the toolstack to only allow a domain to communicate
> with other domains of its choosing, rather than with any domain XSM
> permits.  This would also allow avoiding domain ID reuse problems,
> because a virtual domain ID would stay valid even after the domain
> it refers to no longer exists.  It would need to be explicitly released
> by the guest kernel before it could refer to a different domain.

I'd be all-in for something like that. For context, this is something we
briefly touched on over lunch on the last Xen Summit (it was Juergen, Marek you
and I, I think?). Regardless, this series is only tangentially related. Even if
you do have several domclusters, you'd still need a per-cluster allocator of
domids. For something like domcluster-namespaces to work, we'd need to extend
createdomain to also take a domcluster-id, then the unique domain identifier
comes from a domcluster-id+domid.

I tried shortly after we discussed it to sketch out a credible plan to getting
there, but there were more wrinkles than I expected. You'd definitely want some
domains to be in several namespaces at the same time (The hwdom, at least),
which involves some refcounting I was unsure how to do. Not a major show-stopper
but I hate refcounts with the intensity of a power plant.

grants also become more complicated when you have a domain in several
namespaces, because now you need several grant tables per domain (one per
namespace). The ultimate consequence of this means that if dom0 wants to create
a new domcluster and bind itself to it, now it needs to create a NEW grant table
for itself. Xen is also unaware of this multi-grant table shenanigans so that
needs accounting for too.

Then there's adjustments to be done on the maptrack.

So. I'd really like for this to become a reality, but it requires someone with
time to do it to sit down and walk down the rabbit hole. It was definitely
far deeper than I expected it to be. It doesn't seem to be untractably deep,
but deep enough that I don't want to do it in my spare time. It'd require
coordinated changes at least in Linux, Xen and the toolstack.

Cheers,
Alejandro