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

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


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Date: Thu, 23 Dec 2021 18:45:29 +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=CjkalpuwVcZrwKM7sU7cMK/1kZAsZmV2tUaPNn+OW6o=; b=VhfwnzTuI0gn2JE/x8PSQKWVjmWHddAfi76zJWt/NP5C4CmUy1BN1fJZn6aXRiUnl6TqX6hOLSsTV/y2mHKMMPl1DI96BN99Exxd9tt3Z0O6MtXMLhJGseOsc11ZW0NxxT0aEQhwJoFI+dgZauu39ucUr7jusIkSvhs7rTPMH94XyooYAPsuZcLE9Tcd5T+HnaMZpcRz+Gex2+eN0NIk2qSlsJJT7Ygp4EmFyskScrBy4yZ+p8h8Co4VnNh/i4LFFlomH7upCL8peFTN380Yc4PeoLWwdIVXmbv8qY04V6esRT+o//2caM1eNhfWFMdfoJrsDgF7G1+cTNvsmuNMUA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e30j+Y2lQqWzkl4HXVcwlSeyIDXIwP79EWi+qdS93xUtEMASXU1nQ4yrkm7dEWB0SxfmAVcNAHIA8DrIdh4cw9P+yQnQsKHON2T3n2RHPEy1S5bd6s2Rpk/o5P5QlH2ue5nLFF0eNXt6g3+gK9i3GtP/vzfxjsR+03xOKdDxYjfP0f/hUGDPMCmVsvJY+bCLumCmeKi4b5CokULOIeDSEmEU05vSuavhuLrnyVrax0hlrD6tb9Z/faaCPmI9qNRTVZizSHAudUfmdzKwv/7ZNkggUqozCJdx5fXYRv7FjHxISum2eWk73LF7UoyBEXWT6QS8kRWFnFZzI3NgD+eagA==
  • Cc: Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>
  • Delivery-date: Thu, 23 Dec 2021 18:46:18 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHX8M3KlDaIxIuwGU2+lSkQB5aT3aw3iHyAgAQwJQCAAG+wgIABQZwAgAAWRwCAAOWAgIABAM8AgAEPOwA=
  • Thread-topic: [RFC v1 3/5] xen/arm: introduce SCMI-SMC mediator driver

Hi Stefano, Oleksii,

Stefano Stabellini <sstabellini@xxxxxxxxxx> writes:

> On Wed, 22 Dec 2021, Oleksii Moisieiev wrote:
>> On Tue, Dec 21, 2021 at 01:22:50PM -0800, Stefano Stabellini wrote:
>> > On Tue, 21 Dec 2021, Oleksii Moisieiev wrote:
>> > > Hi Stefano,
>> > > 
>> > > On Mon, Dec 20, 2021 at 04:52:01PM -0800, Stefano Stabellini wrote:
>> > > > On Mon, 20 Dec 2021, Oleksii Moisieiev wrote:
>> > > > > Hi Stefano,
>> > > > > 
>> > > > > On Fri, Dec 17, 2021 at 06:14:55PM -0800, Stefano Stabellini wrote:
>> > > > > > On Tue, 14 Dec 2021, Oleksii Moisieiev wrote:

[...]

>> > > > In general we can't use properties that are not part of the device tree
>> > > > spec, either
>> > > > https://urldefense.com/v3/__https://www.devicetree.org/specifications/__;!!GF_29dbcQIUBPA!kNodtgmOQBc1iO76_6vTK-O1SoLxee_ChowYQiQYC595rMOsrnmof2zmk7BnhXCSnJPN$
>> > > > [devicetree[.]org] or
>> > > > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings__;!!GF_29dbcQIUBPA!kNodtgmOQBc1iO76_6vTK-O1SoLxee_ChowYQiQYC595rMOsrnmof2zmk7BnhXloYUaj$
>> > > > [git[.]kernel[.]org]
>> > > > 
>> > > > "linux,scmi_mem" is currently absent. Are you aware of any upstreaming
>> > > > activities to get "linux,scmi_mem" upstream under
>> > > > Documentation/devicetree/bindings in Linux?
>> > > > 
>> > > > If "linux,scmi_mem" is going upstream in Linux, then we could use it.
>> > > > Otherwise, first "linux,scmi_mem" needs to be added somewhere under
>> > > > Documentation/devicetree/bindings (probably
>> > > > Documentation/devicetree/bindings/firmware/arm,scmi.yaml), then we can
>> > > > work on the Xen code that makes use of it.
>> > > > 
>> > > > Does it make sense?
>> > > > 
>> > > 
>> > > Yes I agree. I think linux,scmi_mem and scmi_devid should be upstreamed.
>> > > I will add those properties to arm,scmi.yaml, mark them as related to 
>> > > XEN and send patch.
>> > 
>> > I didn't realize that linux,scmi_mem and scmi_devid are supposed to be
>> > Xen specific. In general, it would be best not to introduce Xen specific
>> > properties into generic bindings. It is a problem both from a
>> > specification perspective (because it has hard to handle Xen specific
>> > cases in fully generic bindings, especially as those bindings are
>> > maintained as part of the Linux kernel) and from a user perspective
>> > (because now the user has to deal with a Xen-specific dtb, or has to
>> > modify the host dtb to add Xen-specific information by hand.)
>> > 
>> > 
>> > Let me start from scmi_devid.  Why would scmi_devid be Xen-specific? It
>> > looks like a generic property that should be needed for the Linux SCMI
>> > driver too. Why the Linux driver doesn't need it?
>> > 
>> 
>> scmi_devid used during domain build. It passed as input parameter for 
>> SCMI_BASE_SET_DEVICE_PERMISSIONS message.
>> On non-virtualized systems - there is no need of this call, because OS
>> is the only one entity, running on the system.
>
> OK. Even if it is only required for virtualized systems, I think that
> scmi_devid is important enough that should be part of the upstream
> binding. I think it is worth starting an email thread on the LKML with
> Rob Herring and the SCMI maintainers to discuss the addition of
> scmi_devid to the binding.

Agree there. Also I want to point that there are other hypervisors, like
KVM, which may benefit from this.

Another approach is to name this node "xen,scmdi_devid", but I don't
like it.

>> I've chatted with Volodymyr_Babchuk and he gave a great idea to add a
>> list of device_ids to dom.cfg, such as:
>> sci_devs = [ 0, 1, 15, 35 ];
>>

Well, yes. We discussed this possibility, but personally I stick to
idea of re-using dt_dev, as we discussed in the different thread.

>> Using this approach, we can remove scmi_devid from the device tree and
>> just pass a list of scmi_devids to XEN using additional hypercall.
>> We can probably make hypercall taking devid list as input parameter.
>> This will take only 1 hypercall to setup sci permissions.
>
> But how would a user know which are the right SCMI IDs to add to the
> sci_devs list? Would the user have to go and read the reference manual
> of the platform to find the SCMI IDs and then write sci_devs by hand?
> If that is the case, then I think that it would be better to add
> scmi_devid to device tree.
>

Yes, ideally this needs to be done by BSP vendor in the device tree.


-- 
Volodymyr Babchuk at EPAM


 


Rackspace

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