Re: [RFC v1 3/5] xen/arm: introduce SCMI-SMC mediator driver

[Julien Grall <julien@xxxxxxx>]

Hi,

On 24/01/2022 19:06, Stefano Stabellini wrote:
> It looks like XEN_DOMCTL_host_node_by_path and
> XEN_DOMCTL_find_host_compatible_node would also solve the problem but I
> think that a single hypercall that retrieves the entire host DTB would
> be easier to implement
DOMCTL should only be used to handle per-domain information. If we want 
to create a new sub-hypercall of either __HYPERVISOR_platform_op or 
__HYPERVISOR_sysctl_op (not sure which one).
AFAICT, both are versioned.

> and more robust in the long term. >
> hypfs has the advantage that it would create an interface more similar
> to the one people are already used to on Linux systems
> (/proc/device-tree). xl/libxl would have to scan the whole hypfs tree,
> which intuitively I think it would be slower.
Even if you have the binary blob, you would still have to scan the 
device-tree. That said, it is probably going to be potentially a bit 
faster because you have less hypercall.
However, here this is a trade-off between memory use and speed. If you 
want speed, then you may have to transfer up to 2MB every time. So the 
question is do we care more about speed or memory usage?
> Also the feature might be
> harder to implement but I am not sure.
>
> I don't have a strong preference and this is not a stable interface (we
> don't have to be extra paranoid about forward and backward
> compatibility). So I am fine either way. Let's see what the others think
> as well.
My preference would be to use hypfs as this is cleaner than exposing a blob.

However, are we sure we can simply copy the content of the host 
Device-Tree to the guest Device-Tree for SCMI? For instance, I know that 
for device passthrough there are some property that needs to be altered 
for some devices. Hence, why it is not present. Although, I vaguely 
recalled to have written a PoC, not sure if it was posted on the ML.
Cheeers,

--
Julien Grall