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
