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

[Sergiy Kibrik <sergiy_kibrik@xxxxxxxx>]

18.12.24 12:05, Julien Grall:
> 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.
yes, sure

> > > 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?
> > > 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?
> > > 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?
 -Sergiy