Re: [PATCH] xen/arm: Skip Xen specific nodes/properties from hwdom /chosen node

[Michal Orzel <michal.orzel@xxxxxxx>]

Hi Julien,

On 11/09/2023 15:14, Julien Grall wrote:
> 
> 
> Hi,
> 
> On 11/09/2023 13:34, Michal Orzel wrote:
>> Host device tree nodes under /chosen with compatible string
>> "xen,evtchn-v1", "xen,domain-shared-memory-v1" are Xen specific and not
>> meant to be exposed to hardware domain.
> 
> So, how dom0 is meant to discover the static event channel, shared
> memory it can use?

For static shared memory:
A node with this compatible is only meant for Xen since it contains information 
like host-guest mapping.
Xen creates a different node for guests under /reserved-memory.
Linux binding:
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/reserved-memory/xen,shared-memory.txt
Xen node generation:
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/domain_build.c;hb=HEAD#l1407

For static event channels:
This is a bit weird so let me put it in a different way.
1) Xen does not create any node for static evtchn for domU.
2) The booting.txt states:
There is no need to describe the static event channel info in the domU device
tree. Static event channels are only useful in fully static configurations,
and in those configurations, the domU device tree dynamically generated by Xen
is not needed.
3) The "xen,evtchn" property specifies the local port as well as phandle of 
domU node.
dom0 does not have access to domU nodes, therefore exposing a property with not 
existing phandle
makes me think that:
a) point 2) applies to dom0 as well and we should hide this node or
b) there is a missing property for both dom0 and domUs to tell them about 
static local port in a proper way

Exposing Xen specific evtchn node only to dom0 and not to domU with required 
information happen to be found as first value
in xen,evtchn is definitely not a proper solution. Also, there is no Linux 
binding for it.
All that makes me think that the author's idea was not to expose it.

~Michal