[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH v4 8/8] docs: armproposa: l to add separate SCMI node for Xen agent



On Mon, 30 Jun 2025, Julien Grall wrote:
> Hi,
> 
> On 30/06/2025 12:57, Oleksii Moisieiev wrote:
> > KVM [1] is not applicable here as it starts under/inside Linux, so it
> > doesn't have direct access to SCMI, the Linux does.
> > And Linux will see only one SCMI transport (Agent).
> > Seems, the only option possible is virtio-scmi (qemu) - the virtio-scmi
> > potentially can simulate multi-channel,
> > but this is out if scope of this work.
> > QNX [0] relies on configuration files rather than the Device Tree.
> To clarify, I didn't ask to implement anything in KVM or QNX. I asked to write
> the bindings in a way that they are not Xen specific to give a chance to for
> other to re-use them. Yes today KVM and QNX would not use them... But I also
> still don't see why we should actively prevent them to use the bindings you
> come up with...

I agree with Julien. We can still have the property or node under
/chosen to avoid conflicts and confusion while still making the node
more generic so at least in theory it could be reused by other
hypervisors -- remove the "xen," prefix from
"xen,scmi-secondary-agents".



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.