Re: [RFC PATCH] xen/kconfig: allow LATE_HWDOM config for ARM

[Julien Grall <julien@xxxxxxx>]

Hi,

Replying your last two replies in the same thread.


On 24/12/2024 03:41, Sergiy Kibrik wrote:
> 18.12.24 12:05, Julien Grall:
> yes, I had to assign devices to hardware domain manually.

I think it would be easier for the user to say "This is my hardware 
domain" and let Xen assign all the devices, generate the device-tree & co.
> > > > 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.
> I'm not sure which mechanism to use for this. Can it be done by XSM 
> policy management?
For hyperlaunch, Christopher and Daniel proposed to specify the domain 
permissions (e.g. control domain, hardware domain) in the device-tree. I 
think we could re-use a similar approach. See 
docs/designs/launch/hyperlaunch-devicetree.rst for more details.
> > > > 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?
> I suppose it can. But again -- how do I make dom1 (or any other) a 
> control domain instead of dom0?
See above.

> > > > 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?
> Indeed, in my case it works only because there's single domain 
> description in DT.
> If there're many domains in DT, we can't be sure which domain ID each of 
> them would receive at boot, right?
Correct. We don't (and should not) make any guarantee on the ordering. 
If the domid matters, then we would need to introduce a new property 
specifying the domain.
Cheers,

--
Julien Grall