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 <dpsm...@apertussolutions.com>
---
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
