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 <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.
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 >
