On 19.05.2025 21:23, dm...@proton.me wrote: > From: Denis Mukhin <dmuk...@ford.com> > > 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 <jul...@xen.org> ... missed tis earlier suggestion, or else I would have asked the question already there. > --- 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
