|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 05/23] xen/arm: Add capabilities to dom0less
On Thu, 6 Mar 2025, Jason Andryuk wrote:
> Add capabilities property to dom0less to allow building a
> disaggregated system.
>
> Introduce bootfdt.h to contain these constants.
>
> When using the hardware or xenstore capabilities, adjust the grant and
> event channel limits similar to dom0.
>
> Also for the hardware domain, set directmap and iommu. This brings its
> configuration in line with a dom0.
>
> Signed-off-by: Jason Andryuk <jason.andryuk@xxxxxxx>
> ---
> There is overlap with hyperlaunch. The numeric values are the same.
> Hyperlaunch doesn't expose the values in a public header as done here.
> Is this to be expected for dom0less? It seems most of dom0less isn't in
> a header, but just in docs.
>
> Hyperlaunch uses BUILD_CAPS_, but I chose DOMAIN_CAPS_ since there are
> domain-level capabilities.
>
> Only a single xenstore and hardware domain make sense. A check to limit
> to only a single hardware domain is in place - building two breaks. But
> nothing prevents the dom0less configuration from only having multiple
> xenstore domains. Each xenstore domain would have slightly more
> permissions, but only the last one would be used.
> ---
> docs/misc/arm/device-tree/booting.txt | 11 ++++++++++
> xen/arch/arm/dom0less-build.c | 29 +++++++++++++++++++++++++++
> xen/arch/arm/domain.c | 3 ++-
> xen/include/public/bootfdt.h | 27 +++++++++++++++++++++++++
> 4 files changed, 69 insertions(+), 1 deletion(-)
> create mode 100644 xen/include/public/bootfdt.h
>
> diff --git a/docs/misc/arm/device-tree/booting.txt
> b/docs/misc/arm/device-tree/booting.txt
> index ac781c9cc8..490c792ddf 100644
> --- a/docs/misc/arm/device-tree/booting.txt
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -167,6 +167,17 @@ with the following properties:
> Refer to docs/misc/cache_coloring.rst for syntax. This option is
> applicable
> only to Arm64 guests.
>
> +- capabilities
> + Optional. A bit field of domain capabilities for a disaggregated
> + system. A traditional dom0 has all all of these capabilities, and a
> + domU has none of them.
> +
> + 0x1 DOMAIN_CAPS_CONTROL - A privileged, control domain
> + 0x2 DOMAIN_CAPS_HARDWARE - The hardware domain - there can be only 1
> + 0x4 DOMAIN_CAPS_XENSTORE - The xenstore domain - there can be only 1
> +
> + The default is no capabilities.
> +
> - vpl011
>
> An empty property to enable/disable a virtual pl011 for the guest to
> diff --git a/xen/arch/arm/dom0less-build.c b/xen/arch/arm/dom0less-build.c
> index 5a7871939b..068bf99294 100644
> --- a/xen/arch/arm/dom0less-build.c
> +++ b/xen/arch/arm/dom0less-build.c
> @@ -12,6 +12,7 @@
> #include <xen/sizes.h>
> #include <xen/vmap.h>
>
> +#include <public/bootfdt.h>
> #include <public/io/xs_wire.h>
>
> #include <asm/arm64/sve.h>
> @@ -994,6 +995,34 @@ void __init create_domUs(void)
> if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED )
> panic("No more domain IDs available\n");
>
> + if ( dt_property_read_u32(node, "capabilities", &val) )
> + {
> + if ( val & ~DOMAIN_CAPS_MASK )
> + panic("Invalid capabilities (%"PRIx32")\n", val);
> +
> + if ( val & DOMAIN_CAPS_CONTROL )
> + flags |= CDF_privileged;
> +
> + if ( val & DOMAIN_CAPS_HARDWARE )
> + {
> + if ( hardware_domain )
> + panic("Only 1 hardware domain can be specified! (%pd)\n",
> + hardware_domain);
> +
> + d_cfg.max_grant_frames = gnttab_dom0_frames();
> + d_cfg.max_evtchn_port = -1;
max_maptrack_frames = -1 ?
> + flags |= CDF_hardware;
> + flags |= CDF_directmap;
> + iommu = true;
> + }
> +
> + if ( val & DOMAIN_CAPS_XENSTORE )
> + {
> + d_cfg.flags |= XEN_DOMCTL_CDF_xs_domain;
shouldn't we take the opportunity to also set XEN_DOMCTL_CDF_xs_domain
in xen/arch/arm/domain_build.c:create_dom0 ?
> + d_cfg.max_evtchn_port = -1;
Why this one?
> + }
> + }
> +
> if ( dt_find_property(node, "xen,static-mem", NULL) )
> {
> if ( llc_coloring_enabled )
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 3ba959f866..dc4b4e84c1 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -608,7 +608,8 @@ int arch_sanitise_domain_config(struct
> xen_domctl_createdomain *config)
> {
> unsigned int max_vcpus;
> unsigned int flags_required = (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap);
> - unsigned int flags_optional = (XEN_DOMCTL_CDF_iommu |
> XEN_DOMCTL_CDF_vpmu);
> + unsigned int flags_optional = (XEN_DOMCTL_CDF_iommu |
> XEN_DOMCTL_CDF_vpmu |
> + XEN_DOMCTL_CDF_xs_domain );
> unsigned int sve_vl_bits = sve_decode_vl(config->arch.sve_vl);
>
> if ( (config->flags & ~flags_optional) != flags_required )
> diff --git a/xen/include/public/bootfdt.h b/xen/include/public/bootfdt.h
> new file mode 100644
> index 0000000000..4e87aca8ac
> --- /dev/null
> +++ b/xen/include/public/bootfdt.h
> @@ -0,0 +1,27 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Xen Device Tree boot information
> + *
> + * Information for configuring Xen domains created at boot time.
> + */
> +
> +#ifndef __XEN_PUBLIC_BOOTFDT_H__
> +#define __XEN_PUBLIC_BOOTFDT_H__
> +
> +/* Domain Capabilities specified in the "capabilities" property. Use of
> + * this property allows splitting up the monolithic dom0 into separate,
> + * less privileged components. A regular domU has no capabilities
> + * (which is the default if nothing is specified). A traditional dom0
> + * has all three capabilities.*/
The multiline comment coding style is:
/*
* comment
* comment
*/
> +/* Control/Privileged domain capable of affecting other domains. */
> +#define DOMAIN_CAPS_CONTROL (1 << 0)
> +/* Hardware domain controlling physical hardware. Typically providing
> + * backends to other domains. */
> +#define DOMAIN_CAPS_HARDWARE (1 << 1)
> +/* Xenstore domain. */
> +#define DOMAIN_CAPS_XENSTORE (1 << 2)
> +#define DOMAIN_CAPS_MASK (DOMAIN_CAPS_CONTROL | DOMAIN_CAPS_HARDWARE | \
> + DOMAIN_CAPS_XENSTORE)
> +
> +#endif /* __XEN_PUBLIC_BOOTFDT_H__ */
> --
> 2.48.1
>
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |