Re: [RFC 03/38] x86/hyperlaunch: convert max vcpu determination to domain builder

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

On 4/22/25 16:36, Jason Andryuk wrote:
> On 2025-04-19 18:07, Daniel P. Smith wrote:
> > The domain configuration may request more vcpus than are present in 
> > the system.
> > For dom0, the function dom0_max_vcpus() was used to clamp down to 
> > physically
> > available vcpus. Here we are introducing a generalized version,
> > dom_max_vcpus(), that takes a boot domain and sets the max vcpus based 
> > on the
> > lesser of the requested max and the available vcpus.
> >
> > Signed-off-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>
> > ---
> > diff --git a/xen/arch/x86/domain-builder/domain.c b/xen/arch/x86/ 
> > domain-builder/domain.c
> > new file mode 100644
> > index 000000000000..f2277b9e3cf3
> > --- /dev/null
> > +++ b/xen/arch/x86/domain-builder/domain.c
> > @@ -0,0 +1,38 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Copyright (C) 2024, Apertus Solutions, LLC
> > + */
> > +
> > +#include <xen/cpumask.h>
> > +#include <xen/domain.h>
> > +#include <xen/init.h>
> > +#include <xen/sched.h>
> > +
> > +#include <asm/bootinfo.h>
> > +
> > +unsigned int __init dom_max_vcpus(struct boot_domain *bd)
> > +{
> > +    unsigned int limit = bd->mode & BUILD_MODE_PARAVIRT ?
> > +                                    MAX_VIRT_CPUS : HVM_MAX_VCPUS;
> > +
> > +    if ( bd->capabilities & BUILD_CAPS_CONTROL )
> I added xen/include/public/bootfdt.h with DOMAIN_CAPS_CONTROL and the 
> other capabilities to provide common values.
> > +        limit = dom0_max_vcpus();
> dom0_max_vcpus() applies Xen's dom0_max_vcpus command line option.  That 
> is desirable for a traditional dom0.  For a disaggregated, Hyperlaunch 
> system, I'm not sure it's appropriate.  Considering there can multiple 
> control domains, it's more questionable.
> Might it be better to only apply Xen "dom0" command line options to non- 
> hyperlaunch dom0?  Or a domain with all of BUILD_CAPS_CONTROL/HARDWARE/ 
> XENSTORE?
> I guess it could stay as-is, but it seems unusual.
The larger issue is that the cmdline params are going to need to be 
addressed. I see three approaches, first would be to only apply the 
params when there is a single domain with ctrl/hw/xs all set, or the 
second approach would be to change the params to support multiple domain 
statements. Though the second approach has the issue of the need to 
decide how to support the legacy params
v/r,
dps