Re: [RFC v1 5/5] xen/arm: add SCI mediator support for DomUs

[Julien Grall <julien@xxxxxxx>]

Hi,

On 23/12/2021 20:06, Stefano Stabellini wrote:
> On Wed, 22 Dec 2021, Stefano Stabellini wrote:
> > # Future Ideas
> >
> > A great suggestion by Julien is to start supporting the dom0less partial
> > device tree format in xl/libxl as well so that we can have a single
> > "device_tree" option in dom.cfg instead of 4 (device_tree, iomem, irqs,
> > dtdev).
> >
> > Even with that implemented, the user has still to provide a partial dtb,
> > xen,reg and xen,path. I think this is a great step forward and we should
> > do that, if nothing else to make it easier to switch between dom0less
> > and normal domU configurations. But the number of options and
> > information that the user has to provide is still similar to what we
> > have today.
> I have just realized that if we start to parse the partial DTB in
> xl/libxl the same way that we do for dom0less guests (parse "xen,path",
> "xen,reg", and "interrupts", making dtdev, irqs and iomem optional)
> actually we can achieve the goal below thanks to the combination:
> "xen,path" + "xen,force-assign-without-iommu".
>
> In other words, with dom0less we already have a way to specify the link
> to the host node even if the device is not a DMA master. We can do that
> by specifying both xen,path and xen,force-assign-without-iommu for a
> device.
>
> This is just FYI. I am not suggesting we should introduce dom0less-style
> partial DTBs in order to get SCMI support in guests (although it would
> be great to have). I think the best way forward for this series is one
> of the combinations below, like a) + d), or a) + c)
I strongly prefer a) + c) because a warning is easy to miss/ignore. At 
least with the extra property the user made an action to think about it 
and agree that this is the way do it.
It is also easier to spot if we ask the user to provide the 
configuration file.
Cheers,

--
Julien Grall