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

[Jason Andryuk <jason.andryuk@xxxxxxx>]

On 2024-12-24 08:54, Julien Grall wrote:
> 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.
This document is not in sync with Dan's latest work ...

> > 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.
... a more up to date one is here (though it could still change):
https://gitlab.com/xen-project/people/dpsmith/xen/-/commit/4387d0cdc9e0c667a764043fd1474687ee626fca

It includes:

"""
domid
::

  Identifies the domid requested to assign to the domain, Optional.

  Value is an integer.

capabilities
::

  This identifies what system capabilities a domain will fulfill. 
Optional, with the default being none.
  Value is a bit field, currently defined bits are:
    1 - Control domain
    2 - Hardware domain
    3 - Xenstore domain

.. note::  All three bits must be set to have a domain function as a 
traditional dom0. If no domain has the Xenstore domain bit set, then 
none of the domains constructed will have a Xenstore event channel and 
ring buffer allocated. The domain with the Hardware domain bit set will 
be the domain that all domains constructed will have their console event 
channel as the destination domain.
"""

These are not parsed by Xen's dom0less code, but they seem 
straightforward to implement and would provide the needed configuration.
Hmmm, looking at the text, the bits are wrong.  The code uses:
#define BUILD_CAPS_NONE          (0)
#define BUILD_CAPS_CONTROL       (1 << 0)
#define BUILD_CAPS_HARDWARE      (1 << 1)
#define BUILD_CAPS_XENSTORE      (1 << 2)

Regards,
Jason