Re: [PATCH v3 6/7] xen/arm: introduce xen-evtchn dom0less property

[Julien Grall <julien@xxxxxxx>]

Hi Stefano,

On 02/09/2022 03:20, Stefano Stabellini wrote:
> > > diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> > > index 430a1ef445..5579c875d2 100644
> > > --- a/xen/include/xen/device_tree.h
> > > +++ b/xen/include/xen/device_tree.h
> > > @@ -82,6 +82,7 @@ struct dt_device_node {
> > >        dt_phandle phandle;
> > >        char *full_name;
> > >        domid_t used_by; /* By default it's used by dom0 */
> > > +    bool_t static_evtchn_created;
> > I can see why you want to add the boolean in dt_device_node. However, I
> > dislike this approach because this feels an abuse of dt_device_node and the
> > field is only used at boot.
> >
> > So this seems to be a bit of a waste to include it in the structure (even if
> > we are re-using padding today).
> >
> > I don't have a solution that is has trivial as this approach. However, at
> > minimum we should document this is a HACK and should be remove if we need
> > space in the structure.
> I would move static_evtchn_created just above (or below) "bool
> is_protected". It would still re-use the padding and it would be
> closer to another more similar field of the struct.
>
> The only other option that I can think of would be to use port_is_valid,
> instead of static_evtchn_created, to check that the port has already
> been allocated, but we wouldn't be able to tell if it is a static evtchn
> or simply unavailable for other reasons
You don't need to know the event channel was statically allocated. If 
you have access to the event channel, then you can easily find out what 
is the remote port.
> and it would require more device
> tree parsing.
The parsing is indeed the big cons. Hence, why I hadn't suggest it.

Cheers,

--
Julien Grall