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.
Regards,
Jason
