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

Re: [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>
  • Date: Wed, 16 Feb 2022 17:41:25 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NX+SaukE6/joZlH4ugSUUza9ISs4abl66HQvh0Dilms=; b=MkiULN1i/B/XrhBjDCPIe7ufYXIrVStojAe3FjGTs5YXBYZbY0iPNgDp8oMFeWGEJLLRlIb2FynJ9RFFHzEWvU4bWu4bV6ebWwMhDOMn5UyZRdBFJ6aG7E79LlX9PfunYryoV2xQ152VUHp9PoAf+hGyo3xs2D0Fwgc1Ape53TahSDBggFzdgnOuPJdkm/alyeokDyTQEg8WlITVhqkMF8UejewHzo/WpaxaXcA7smnMp1D85Ul5tv2c2q0eFL6tPaIOYBA51nHG41FEQvSQqm+tZBVBLXtaopI4DyJHHEb2e5rZPEWCNHCy7MTvNQNfRjn7CjE/q2+9SmaO5pe6JA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iA4EFxD2fVNCIHoClymZrLmPngOvJTPvnXIjrowXoMSTGqtVTrqSRxRDfruNbF+WUXF1i4KNkF5B+v3mJRandXcIi3xQjWcPKZavrfZBy2MY39COjDffXSjePeT5St+8VXbjWzFht/hRmd9iJo3QT/bRHST0a20lpIUOO5tl5W9z9xCdrnr7AEwNUQBV3wkxs282JpdbVYlLkLUXcZlMKITQLREJeMa+nYVTzjuB29MFitvGfLcj5jnn2TVDLIsaVs9qftINPZ0t8heh3sbcAuiENX2oTUVfnrgMWvL2QM/t4tnTXpLXo8BiMVUFx72E7Q5q/+h2vOF4AHNrJzCNdA==
  • Cc: Bertrand Marquis <bertrand.marquis@xxxxxxx>, Julien Grall <julien@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Wed, 16 Feb 2022 17:42:02 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHYHRW24Dmb0qV8ZkqAv39Pf6/nVayODW6AgAAg+ICAAAmzAIABqiEAgAMLQQCAAAQDgIAABruAgACrggCAAtruAA==
  • Thread-topic: [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver

Hi Stefano,

On Mon, Feb 14, 2022 at 02:05:18PM -0800, Stefano Stabellini wrote:
> On Mon, 14 Feb 2022, Oleksii Moisieiev wrote:
> > Hi Bertrand,
> > 
> > On Mon, Feb 14, 2022 at 11:27:21AM +0000, Bertrand Marquis wrote:
> > > Hi Oleksii,
> > > 
> > > > On 14 Feb 2022, at 11:13, Oleksii Moisieiev 
> > > > <Oleksii_Moisieiev@xxxxxxxx> wrote:
> > > > 
> > > > Hi Julien,
> > > > 
> > > > On Sat, Feb 12, 2022 at 12:43:56PM +0000, Julien Grall wrote:
> > > >> Hi,
> > > >> 
> > > >> On 11/02/2022 11:18, Bertrand Marquis wrote:
> > > >>> Do you plan to add support for other boards ?
> > > >>> 
> > > >>> Did you discuss more in general with the linux kernel guys to see if 
> > > >>> this
> > > >>> approach was agreed and will be adopted by other manufacturers ?
> > > >>> 
> > > >>> All in all I think this is a good idea but I fear that all this will 
> > > >>> actually only
> > > >>> be used by one board or one manufacturer and other might use a 
> > > >>> different
> > > >>> strategy, I would like to unrisk this before merging this in Xen.
> > > >> 
> > > >> In the past we merged code that would only benefits one vendor (i.e. 
> > > >> EEMI).
> > > >> That said, this was a vendor specific protocol. I believe the 
> > > >> situation is
> > > >> different here because the spec is meant to be generic.
> > > >> 
> > > >>> @julien and Stefano: what is your view here ?
> > > >> 
> > > >> I share the same concerns as you. I think we need to make sure all the
> > > >> pieces we rely on (e.g. firmware, DT bindings) have been agreed before 
> > > >> we
> > > >> can merge such code in Xen.
> > > >> 
> > > >> The first step is to have all the pieces available in public so they 
> > > >> can be
> > > >> reviewed and tested together.
> > > >>
> > > >> Oleksii, on a separate e-mail, you said you made change for ATF. How 
> > > >> much of
> > > >> those changes was related to support for Xen? If they are some, then I 
> > > >> think
> > > >> they should be upstreamed first.
> > > >> 
> > > > 
> > > > Let me share changes, that were done to AT-F and Linux kernel
> > > > device-tree in terms of the SCMI mediator POC.
> > > > Changes to the Linux kernel:
> > > > https://urldefense.com/v3/__https://github.com/oleksiimoisieiev/arm-trusted-firmware/pull/4__;!!GF_29dbcQIUBPA!je9Cu0n0498Yn76OLWjxxVaB7jWJtyWycHX0YARezTnc7aYHpGRJ8tSxHqIC0fTMUUSV$
> > > >  [github[.]com]
> > > > Based on renesas-rcar linux-bsp, branch v5.10/rcar-5.0.0.rc5
> > > > 
> > > > Changes to AT-F:
> > > > https://urldefense.com/v3/__https://github.com/oleksiimoisieiev/linux-bsp/pull/3__;!!GF_29dbcQIUBPA!je9Cu0n0498Yn76OLWjxxVaB7jWJtyWycHX0YARezTnc7aYHpGRJ8tSxHqIC0eDKS3ge$
> > > >  [github[.]com]
> > > > Based on renesas-rcar/arm-trusted-firmware branch rcar_gen3_v2.5.
> > > 
> > > You inverted the links but thanks this is really useful.
> > > 
> > 
> > That's strange. Links looks good from xen.markmail.org interface.
> > 
> > > Did you push the ATF changes to mainstream ATF or discuss those with
> > > the maintainers ?
> > 
> > No. We did changes in ATF as a proof of concept.
> > 
> > > 
> > > The strategy overall is nice but we need to make sure this is accepted and
> > >  merged by all parties (ATF and Linux) to make sure the support for this 
> > > will
> > > not only be available in Xen and for one board.
> 
> +1
> 
> 
> > I've prepared patch to Linux kernel, which is introducing scmi_devid
> > binding, needed to set device permissions via SCMI. I've contacted
> > Sudeep Holla <sudeep.holla@xxxxxxx>, who is the maintainer of the SCMI 
> > protocol
> > drivers. Waiting for the response.
> > 
> > Changes to ATF are not Xen specific and were done in terms of POC. We do
> > not have plans to upstream those changes right now.
> 
> If this work relies on a new interface in ATF, and the interface is not
> vendor-specific, then at least the interface (if not the code) should be
> reviewed and accepted by ATF.
> 
> Otherwise we risk ending up with an upstream SCMI implementation in Xen
> that cannot be used anywhere, except the PoC. To make things worse, this
> could happen:
> 
> - we upstream the SCMI mediator to Xen
> - we upstream any required changes to Linux
> - ATF rejects the SCMI-related interface changes
> - ATF comes up with a difference interface
> 
> At this point we would have to deprecate the implementation in Xen. It
> might also be difficult to do so due to versioning issues. We would
> need to be able to detect which version of ATF we are running on, to
> distinguish the ATF PoC version that works with the old interface from
> the new ATF version that supports a different interface.
> 
> To avoid this kind of issues we typically expect that all relevant
> communities agree on the public interfaces before upstreaming the code.

That's sound reasonable.
I'll contact with AT-F maintainers. Maybe I'll be able to upstream SCMI
to AT-F.
Also I hope I'll be able to contact Linux kernel SCMI maintainers and
discuss device-tree structure.

Best regards,
Oleksii


 


Rackspace

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