On Tue, May 20, 2025 at 08:04:14AM +0200, Jan Beulich wrote:
> On 19.05.2025 21:23, dm...@proton.me wrote:
> > From: Denis Mukhin
> >
> > Embedded deployments of Xen do not need to have support for more than dozen
> > of
> > domains.
> >
> > Introduce build-time configuration option to limit the number of domains
> > during
> > run-time.
>
> I fear I don't see the (sufficiently meaningful) gain of this. And I must
> have ...
>
> > Suggested-by: Julien Grall
>
> ... missed tis earlier suggestion, or else I would have asked the question
> already
> there.
The code change is based on the feedback here:
https://lore.kernel.org/xen-devel/2e5afdf1-3913-4b6f-86ea-21b3ccd08...@xen.org/
It probably should have been sent as an RFC change.
>
> > --- a/xen/arch/arm/tee/ffa.c
> > +++ b/xen/arch/arm/tee/ffa.c
> > @@ -333,8 +333,9 @@ static int ffa_domain_init(struct domain *d)
> > */
> > BUILD_BUG_ON(DOMID_FIRST_RESERVED >= UINT16_MAX);
> > BUILD_BUG_ON((DOMID_MASK & BIT(15, U)) != 0);
> > +BUILD_BUG_ON(DOMID_FIRST_RESERVED < CONFIG_MAX_DOMID);
>
> We want this check, yes, but in common code. It's entirely unrelated to Arm's
> TEE.
>
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -576,4 +576,11 @@ config BUDDY_ALLOCATOR_SIZE
> > Amount of memory reserved for the buddy allocator to serve Xen heap,
> > working alongside the colored one.
> >
> > +config MAX_DOMID
> > + int "Maximum number of non-system domains"
>
> Hmm, without clarifying what a system domain is (is hwdom one? is a control
> domain one), I fear this may be ambiguous to users.
>
> Jan
>
