| 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
hi Julien, 17.12.24 14:42, Julien Grall: > Hi, > > Can you clarify why this is an RFC? > The code for LATE_HWDOM support on ARM seems to be already in place and working, yet I'm not sure that such configuration is ready to be exposed for users (well, probably not ready yet, considering Daniel's comments regarding XSM later in this thread). > 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? I agree, it should have better description. This is to split dom0 permissions into control-only and hardware-only domains, much like it can be done in x86. > > If so, why can't the hardware domain stay as dom0 and you remove the > feature you don't want (e.g. control domain)? control domain is still needed, but as a separate instance & without hardware access. > > 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... > I append "hardware_dom=1" to xen,xen-bootargs in host's device tree and it works. >> >> 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? my assumption was that DOM0LESS_BOOT only available on ARM, hence other arch won't be affected. -Sergiy
17.12.24 15:02, Jan Beulich: > 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. Yes, on x86 it's started by toolstack. This is not supported on ARM. However dom0less can already handle hardware domain initialization on ARM, without much of an additional changes. -Sergiy
18.12.24 03:17, Daniel P. Smith: >> 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". yes, you're correct > > 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. > will check this out, thank you for suggestion! -Sergiy
On 18/12/2024 09:52, Sergiy Kibrik wrote: > hi Julien, > > 17.12.24 14:42, Julien Grall: >> Hi, >> >> Can you clarify why this is an RFC? >> > > The code for LATE_HWDOM support on ARM seems to be already in place and > working, yet I'm not sure that such configuration is ready to be exposed > for users (well, probably not ready yet, considering Daniel's comments > regarding XSM later in this thread). Thanks. In the future, for RFCs, I would suggest to add a section after your commit message (generally after ---) to describe a bit more what you input you expect from the reviewers. > > >> 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? > > I agree, it should have better description. > This is to split dom0 permissions into control-only and hardware-only > domains, much like it can be done in x86. I don't believe you need the late_hwdom feature to do that on Arm. In the case of dom0less, you are creating the domains at boot, so at the point you can decide who does what. You don't need to transfer the permissions (which seems odd in the context of dom0less) to a new domain after dom0 is created. > >> >> If so, why can't the hardware domain stay as dom0 and you remove the >> feature you don't want (e.g. control domain)? > > control domain is still needed, but as a separate instance & without > hardware access. Sure. But the control domain doesn't need to be dom0, it could be dom1, right? > >> >> 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... >> > > I append "hardware_dom=1" to xen,xen-bootargs in host's device tree and > it works. AFAIU, the domain needs to be explicitely created. How do you do that? Is it just describing the domain in the DT? If so, how does it work if there are multiple domain described in the DT? > >>> >>> 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? > > my assumption was that DOM0LESS_BOOT only available on ARM, hence other > arch won't be affected. Well... There are effort to support dom0less_boot on other architectures. But to be honest, I am not convinced that we should enable LATE_HWDOM here. Cheers,
On 17/12/2024 11:47 am, 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. > > 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) > help > Allows the creation of a dedicated hardware domain distinct from > domain 0 that manages devices without needing access to other To ask a questions not asked elsewhere on this thread. We are expecting Hyperlaunch to supersede and entirely replace what is currently x86's idea of split control/hwdom, to this point where this symbol is even removed. Has this plan changed? ~Andrew
On 18/12/2024 10:05, Julien Grall wrote: > > > On 18/12/2024 09:52, Sergiy Kibrik wrote: >> hi Julien, >> >> 17.12.24 14:42, Julien Grall: >>> Hi, >>> >>> Can you clarify why this is an RFC? >>> >> >> The code for LATE_HWDOM support on ARM seems to be already in place >> and working, yet I'm not sure that such configuration is ready to be >> exposed for users (well, probably not ready yet, considering Daniel's >> comments regarding XSM later in this thread). > > Thanks. In the future, for RFCs, I would suggest to add a section after > your commit message (generally after ---) to describe a bit more what > you input you expect from the reviewers. > >> >> >>> 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? >> >> I agree, it should have better description. >> This is to split dom0 permissions into control-only and hardware-only >> domains, much like it can be done in x86. > > I don't believe you need the late_hwdom feature to do that on Arm. In > the case of dom0less, you are creating the domains at boot, so at the > point you can decide who does what. > > You don't need to transfer the permissions (which seems odd in the > context of dom0less) to a new domain after dom0 is created. > >> >>> >>> If so, why can't the hardware domain stay as dom0 and you remove the >>> feature you don't want (e.g. control domain)? >> >> control domain is still needed, but as a separate instance & without >> hardware access. > > Sure. But the control domain doesn't need to be dom0, it could be dom1, > right? > >> >>> >>> 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... >>> >> >> I append "hardware_dom=1" to xen,xen-bootargs in host's device tree >> and it works. > > AFAIU, the domain needs to be explicitely created. How do you do that? > Is it just describing the domain in the DT? If so, how does it work if > there are multiple domain described in the DT? I just had a look at the code. I don't see how this change and simply adding "hardware_dom=X" is sufficient. In addition to what I wrote above, Dom0 will be the first domain created and we will assign all the devices and mappings. When the hardware domain is created later on, dom0 will still have those mappings and devices. That's unless you list all the devices in the device-tree as not assigned to dom0 and then assign them manually to the hardware domain. I would also expect that the hardware domain wants to use the same memory layout as the host. But that's not necessary for the control domain. So surely you need something more in the device-tree? Cheers,
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(-)