| Message ID | 20241217114719.2870676-1-Sergiy_Kibrik@epam.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC] xen/kconfig: allow LATE_HWDOM config for ARM | expand |
Hi, Can you clarify why this is an RFC? On 17/12/2024 11:47, Sergiy Kibrik wrote: > Allow to build ARM configuration with support for initializing hardware domain. > On ARM it is only possible to start hardware domain in multiboot mode, so > dom0less support is required. This is reflected by dependency on DOM0LESS_BOOT > instead of directly depending on ARM config option. I am a bit confused with the explanation. We already have an hardware domain on Arm. It is dom0. So what are you trying to achieve? Is this remove some permissions from the hardware domain? If so, why can't the hardware domain stay as dom0 and you remove the feature you don't want (e.g. control domain)? Are you sure this patch is sufficient to use the late hwdom feature? Looking at the code, to enable the late hwdom, the user needs to provide a domid on the command line. But AFAICT, there is no way to provide a domain ID in the DOM0LESS case... > > Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> > --- > xen/common/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/common/Kconfig b/xen/common/Kconfig > index 90268d9249..7368ca8208 100644 > --- a/xen/common/Kconfig > +++ b/xen/common/Kconfig > @@ -374,7 +374,7 @@ endchoice > config LATE_HWDOM > bool "Dedicated hardware domain" > default n > - depends on XSM && X86 > + depends on XSM && (X86 || DOM0LESS_BOOT) This will enable LATE_HWDOM for other arch. Is this what we want? > help > Allows the creation of a dedicated hardware domain distinct from > domain 0 that manages devices without needing access to other Cheers,
On 17.12.2024 12:47, Sergiy Kibrik wrote: > Allow to build ARM configuration with support for initializing hardware domain. > On ARM it is only possible to start hardware domain in multiboot mode, so > dom0less support is required. I don't follow this. Late hwdom is supposed to be started by a (minimal) toolstack iirc. Jan
> On 17/12/2024 11:47, Sergiy Kibrik wrote: >> Allow to build ARM configuration with support for initializing >> hardware domain. >> On ARM it is only possible to start hardware domain in multiboot mode, so >> dom0less support is required. This is reflected by dependency on >> DOM0LESS_BOOT >> instead of directly depending on ARM config option. Just to make sure my assumption is correct, you are looking to do a multi-domain construction at boot time, with at least two domains. One of those two domains is the "control domain" and one is the "hardware domain", aka late hwdom except it's not constructed "late". If you want such a configuration, I would highly recommend you first enable setting flask labels via dom0less (assuming it is not there) before lighting this feature up. This is because the dummy/base policy has no support for differentiating between a "control domain" and a "hardware domain". What you really would end up with is two control domains, with one also having control over hardware. v/r dps
diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 90268d9249..7368ca8208 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -374,7 +374,7 @@ endchoice config LATE_HWDOM bool "Dedicated hardware domain" default n - depends on XSM && X86 + depends on XSM && (X86 || DOM0LESS_BOOT) help Allows the creation of a dedicated hardware domain distinct from domain 0 that manages devices without needing access to other
Allow to build ARM configuration with support for initializing hardware domain. On ARM it is only possible to start hardware domain in multiboot mode, so dom0less support is required. This is reflected by dependency on DOM0LESS_BOOT instead of directly depending on ARM config option. Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@epam.com> --- xen/common/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)