On Thu Sep 4, 2025 at 10:15 PM CEST, Demi Marie Obenour wrote:
> On 8/29/25 19:21, dmuk...@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-dmuk...@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
