* [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface @ 2020-06-01 9:45 ` Sudeep Holla 0 siblings, 0 replies; 45+ messages in thread From: Sudeep Holla @ 2020-06-01 9:45 UTC (permalink / raw) To: Will Deacon, devicetree, linux-arm-kernel Cc: Sudeep Holla, linux-kernel, Marc Zyngier Hi All, Sorry for posting in the middle of merge window and I must have done this last week itself. This is not the driver I had thought about posting last week. After I started cleaning up and looking at Will's KVM prototype[1] for PSA FF-A (previously known as SPCI), I got more doubts on alignment and dropped huge chunk of interface APIs in the driver in order to keep it simple, and get aligned more with that prototype and avoid scanning lots of code unnecessary. Here are few things to clarify: 1. DT bindings --------------- I was initially against adding bindings for Tx/Rx buffers for partitions. As per the spec, an endpoint could allocate the buffer pair and use the FFA_RXTX_MAP interface to map it with the Hypervisor(KVM here). However looking at the prototype and also I remember you mentioning that it is not possible to manage buffers in that way. Please confirm if you plan to add the buffer details fetcthing them through ioctls in KVM and adding them to VM DT nodes in KVM userspace. I will update the bindings accordingly. 2. Driver --------- a. Support for multiple partitions in a VM ------------------------------------------ I am not sure if there is need for supporting multiple partitions within a VM. It should be possible to do so as I expect to create device for each partition entry under arm-psa-ffa devicetree node. However, I don't want to assume something that will never be a usecase. However I don't think this will change must of the abstraction as we need to keep the interface API implementation separate to support different partitions on various platforms. b. SMCCC interface ------------------ This is something I messed up completely while trying to add support for SMCCC v1.2. It now supports x0-x17 as parameter registers(input) and return registers(output). I started simple with x0-x7 as both input and output as PSA FF-A needs that at most. But extending to x0-x17 then became with messy in my implementation. That's the reason I dropped it completely here and thought of checking it first. Do we need to extend the optimisations that were done to handle ARCH_WORKAROUND_{1,2}. Or should be just use a version with x0-x7 as both input and ouput. Hyper-V guys need full x0-x17 support. I need some guidance as what is the approach preferred ? 3. Partitions ------------- I am not sure if we have a full define partition that we plan to push upstream. Without one, we can have a sample/example partition to test all the interface APIs, but is that fine with respect to what we want upstream ? Any other thoughts that helps to test the driver ? Sorry for long email and too many questions, but I thought it is easier this way to begin with than throwing huge code implementing loads of APIs with no users(expect example partition) especially that I am posting this during merge window. Sudeep Holla (3): dt-bindings: Add ARM PSA FF binding for non-secure VM partitions firmware: Add support for PSA FF-A transport for VM partitions firmware: Add example PSA FF-A non-secure VM partition .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 ++++ drivers/firmware/Kconfig | 1 + drivers/firmware/Makefile | 1 + drivers/firmware/arm_psa_ffa/Kconfig | 22 ++ drivers/firmware/arm_psa_ffa/Makefile | 3 + drivers/firmware/arm_psa_ffa/driver.c | 250 ++++++++++++++++++ drivers/firmware/arm_psa_ffa/partition.c | 71 +++++ include/linux/arm_psa_ffa.h | 42 +++ 8 files changed, 437 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt create mode 100644 drivers/firmware/arm_psa_ffa/Kconfig create mode 100644 drivers/firmware/arm_psa_ffa/Makefile create mode 100644 drivers/firmware/arm_psa_ffa/driver.c create mode 100644 drivers/firmware/arm_psa_ffa/partition.c create mode 100644 include/linux/arm_psa_ffa.h -- 2.17.1 ^ permalink raw reply [flat|nested] 45+ messages in thread
* [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface @ 2020-06-01 9:45 ` Sudeep Holla 0 siblings, 0 replies; 45+ messages in thread From: Sudeep Holla @ 2020-06-01 9:45 UTC (permalink / raw) To: Will Deacon, devicetree, linux-arm-kernel Cc: Marc Zyngier, linux-kernel, Sudeep Holla Hi All, Sorry for posting in the middle of merge window and I must have done this last week itself. This is not the driver I had thought about posting last week. After I started cleaning up and looking at Will's KVM prototype[1] for PSA FF-A (previously known as SPCI), I got more doubts on alignment and dropped huge chunk of interface APIs in the driver in order to keep it simple, and get aligned more with that prototype and avoid scanning lots of code unnecessary. Here are few things to clarify: 1. DT bindings --------------- I was initially against adding bindings for Tx/Rx buffers for partitions. As per the spec, an endpoint could allocate the buffer pair and use the FFA_RXTX_MAP interface to map it with the Hypervisor(KVM here). However looking at the prototype and also I remember you mentioning that it is not possible to manage buffers in that way. Please confirm if you plan to add the buffer details fetcthing them through ioctls in KVM and adding them to VM DT nodes in KVM userspace. I will update the bindings accordingly. 2. Driver --------- a. Support for multiple partitions in a VM ------------------------------------------ I am not sure if there is need for supporting multiple partitions within a VM. It should be possible to do so as I expect to create device for each partition entry under arm-psa-ffa devicetree node. However, I don't want to assume something that will never be a usecase. However I don't think this will change must of the abstraction as we need to keep the interface API implementation separate to support different partitions on various platforms. b. SMCCC interface ------------------ This is something I messed up completely while trying to add support for SMCCC v1.2. It now supports x0-x17 as parameter registers(input) and return registers(output). I started simple with x0-x7 as both input and output as PSA FF-A needs that at most. But extending to x0-x17 then became with messy in my implementation. That's the reason I dropped it completely here and thought of checking it first. Do we need to extend the optimisations that were done to handle ARCH_WORKAROUND_{1,2}. Or should be just use a version with x0-x7 as both input and ouput. Hyper-V guys need full x0-x17 support. I need some guidance as what is the approach preferred ? 3. Partitions ------------- I am not sure if we have a full define partition that we plan to push upstream. Without one, we can have a sample/example partition to test all the interface APIs, but is that fine with respect to what we want upstream ? Any other thoughts that helps to test the driver ? Sorry for long email and too many questions, but I thought it is easier this way to begin with than throwing huge code implementing loads of APIs with no users(expect example partition) especially that I am posting this during merge window. Sudeep Holla (3): dt-bindings: Add ARM PSA FF binding for non-secure VM partitions firmware: Add support for PSA FF-A transport for VM partitions firmware: Add example PSA FF-A non-secure VM partition .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 ++++ drivers/firmware/Kconfig | 1 + drivers/firmware/Makefile | 1 + drivers/firmware/arm_psa_ffa/Kconfig | 22 ++ drivers/firmware/arm_psa_ffa/Makefile | 3 + drivers/firmware/arm_psa_ffa/driver.c | 250 ++++++++++++++++++ drivers/firmware/arm_psa_ffa/partition.c | 71 +++++ include/linux/arm_psa_ffa.h | 42 +++ 8 files changed, 437 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt create mode 100644 drivers/firmware/arm_psa_ffa/Kconfig create mode 100644 drivers/firmware/arm_psa_ffa/Makefile create mode 100644 drivers/firmware/arm_psa_ffa/driver.c create mode 100644 drivers/firmware/arm_psa_ffa/partition.c create mode 100644 include/linux/arm_psa_ffa.h -- 2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 45+ messages in thread
* [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions 2020-06-01 9:45 ` Sudeep Holla @ 2020-06-01 9:45 ` Sudeep Holla -1 siblings, 0 replies; 45+ messages in thread From: Sudeep Holla @ 2020-06-01 9:45 UTC (permalink / raw) To: Will Deacon, devicetree, linux-arm-kernel Cc: Sudeep Holla, linux-kernel, Marc Zyngier Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition at virtual interface(VMs). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> --- .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt diff --git a/Documentation/devicetree/bindings/arm/arm,psa-ffa.txt b/Documentation/devicetree/bindings/arm/arm,psa-ffa.txt new file mode 100644 index 000000000000..ee543fb5b397 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,psa-ffa.txt @@ -0,0 +1,47 @@ +Arm Platform Security Architecture(PSA) Firmware Framework(FF) for Armv8-A +-------------------------------------------------------------------------- + +This binding is intended to define the interface the firmware framework +implementing the Non-secure partitions/endpoints(mostly VMs) as described +in ARM document ARM DEN 0077A ("Arm Platform Security Architecture +Firmware Framework for Arm v8-A") [0] + +In the case of a Non-secure virtual FF-A instance, the hypervisor +(e.g. Linux KVM) can use this binding to create and launch VM partitions. + +The SMCCC conduit available in the VM partition itself is used and hence +there is no explicit binding to specify the conduit used for PSA FFA +interface. + +Required properties: + +- compatible : Should be one of: + "arm,psa-ffa" + +- One or more child nodes, each describing an PSA FFA partition using the + following required properties: + + - compatible: Should be one of: + "arm,psa-ffa-partition" + + - uuid : The 128-bit UUID [2] of the service implemented by this partition, + represented as a string. + +[0] https://developer.arm.com/docs/den0077/latest +[1] https://tools.ietf.org/html/rfc4122 + +Example: + + #address-cells = <2>; + #size-cells = <2>; + + firmware { + psa-ffa { + compatible = "arm,psa-ffa"; + + partition0: psa_ffa_partition { + compatible = "arm,psa-ffa-partition"; + uuid = "12345678-9abc-def0-1234-56789abcdef0"; + }; + }; + }; -- 2.17.1 ^ permalink raw reply related [flat|nested] 45+ messages in thread
* [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions @ 2020-06-01 9:45 ` Sudeep Holla 0 siblings, 0 replies; 45+ messages in thread From: Sudeep Holla @ 2020-06-01 9:45 UTC (permalink / raw) To: Will Deacon, devicetree, linux-arm-kernel Cc: Marc Zyngier, linux-kernel, Sudeep Holla Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition at virtual interface(VMs). Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> --- .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt diff --git a/Documentation/devicetree/bindings/arm/arm,psa-ffa.txt b/Documentation/devicetree/bindings/arm/arm,psa-ffa.txt new file mode 100644 index 000000000000..ee543fb5b397 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,psa-ffa.txt @@ -0,0 +1,47 @@ +Arm Platform Security Architecture(PSA) Firmware Framework(FF) for Armv8-A +-------------------------------------------------------------------------- + +This binding is intended to define the interface the firmware framework +implementing the Non-secure partitions/endpoints(mostly VMs) as described +in ARM document ARM DEN 0077A ("Arm Platform Security Architecture +Firmware Framework for Arm v8-A") [0] + +In the case of a Non-secure virtual FF-A instance, the hypervisor +(e.g. Linux KVM) can use this binding to create and launch VM partitions. + +The SMCCC conduit available in the VM partition itself is used and hence +there is no explicit binding to specify the conduit used for PSA FFA +interface. + +Required properties: + +- compatible : Should be one of: + "arm,psa-ffa" + +- One or more child nodes, each describing an PSA FFA partition using the + following required properties: + + - compatible: Should be one of: + "arm,psa-ffa-partition" + + - uuid : The 128-bit UUID [2] of the service implemented by this partition, + represented as a string. + +[0] https://developer.arm.com/docs/den0077/latest +[1] https://tools.ietf.org/html/rfc4122 + +Example: + + #address-cells = <2>; + #size-cells = <2>; + + firmware { + psa-ffa { + compatible = "arm,psa-ffa"; + + partition0: psa_ffa_partition { + compatible = "arm,psa-ffa-partition"; + uuid = "12345678-9abc-def0-1234-56789abcdef0"; + }; + }; + }; -- 2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions 2020-06-01 9:45 ` Sudeep Holla @ 2020-06-09 22:35 ` Rob Herring -1 siblings, 0 replies; 45+ messages in thread From: Rob Herring @ 2020-06-09 22:35 UTC (permalink / raw) To: Sudeep Holla Cc: Will Deacon, devicetree, linux-arm-kernel, linux-kernel, Marc Zyngier On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > at virtual interface(VMs). > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > --- > .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > 1 file changed, 47 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt I'm hoping this goes away if the firmware is discoverable, but if not DT bindings are DT schema now. Rob ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions @ 2020-06-09 22:35 ` Rob Herring 0 siblings, 0 replies; 45+ messages in thread From: Rob Herring @ 2020-06-09 22:35 UTC (permalink / raw) To: Sudeep Holla Cc: devicetree, Will Deacon, linux-kernel, linux-arm-kernel, Marc Zyngier On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > at virtual interface(VMs). > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > --- > .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > 1 file changed, 47 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt I'm hoping this goes away if the firmware is discoverable, but if not DT bindings are DT schema now. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions 2020-06-09 22:35 ` Rob Herring @ 2020-06-10 7:43 ` Will Deacon -1 siblings, 0 replies; 45+ messages in thread From: Will Deacon @ 2020-06-10 7:43 UTC (permalink / raw) To: Rob Herring Cc: Sudeep Holla, devicetree, linux-arm-kernel, linux-kernel, Marc Zyngier On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > > Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > > at virtual interface(VMs). > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > --- > > .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > > 1 file changed, 47 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > > I'm hoping this goes away if the firmware is discoverable, but if not DT > bindings are DT schema now. We'll need the binding for the kvm host side, because there are plenty of partition properties that are not discoverable (e.g. number of vCPUs). I'll have a go a yamlifying what I have... Will ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions @ 2020-06-10 7:43 ` Will Deacon 0 siblings, 0 replies; 45+ messages in thread From: Will Deacon @ 2020-06-10 7:43 UTC (permalink / raw) To: Rob Herring Cc: devicetree, Marc Zyngier, linux-kernel, linux-arm-kernel, Sudeep Holla On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > > Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > > at virtual interface(VMs). > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > --- > > .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > > 1 file changed, 47 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > > I'm hoping this goes away if the firmware is discoverable, but if not DT > bindings are DT schema now. We'll need the binding for the kvm host side, because there are plenty of partition properties that are not discoverable (e.g. number of vCPUs). I'll have a go a yamlifying what I have... Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions 2020-06-10 7:43 ` Will Deacon @ 2020-06-10 13:56 ` Rob Herring -1 siblings, 0 replies; 45+ messages in thread From: Rob Herring @ 2020-06-10 13:56 UTC (permalink / raw) To: Will Deacon Cc: Sudeep Holla, devicetree, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, linux-kernel, Marc Zyngier On Wed, Jun 10, 2020 at 1:43 AM Will Deacon <will@kernel.org> wrote: > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > > On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > > > Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > > > at virtual interface(VMs). > > > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > --- > > > .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > > > 1 file changed, 47 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > > > > I'm hoping this goes away if the firmware is discoverable, but if not DT > > bindings are DT schema now. > > We'll need the binding for the kvm host side, because there are plenty > of partition properties that are not discoverable (e.g. number of vCPUs). BTW, there's already a partitioning binding for Power in ePAPR. I've not paid much attention to it, but maybe it could be useful here. Rob ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions @ 2020-06-10 13:56 ` Rob Herring 0 siblings, 0 replies; 45+ messages in thread From: Rob Herring @ 2020-06-10 13:56 UTC (permalink / raw) To: Will Deacon Cc: devicetree, Marc Zyngier, linux-kernel, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Sudeep Holla On Wed, Jun 10, 2020 at 1:43 AM Will Deacon <will@kernel.org> wrote: > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > > On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > > > Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > > > at virtual interface(VMs). > > > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > --- > > > .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > > > 1 file changed, 47 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > > > > I'm hoping this goes away if the firmware is discoverable, but if not DT > > bindings are DT schema now. > > We'll need the binding for the kvm host side, because there are plenty > of partition properties that are not discoverable (e.g. number of vCPUs). BTW, there's already a partitioning binding for Power in ePAPR. I've not paid much attention to it, but maybe it could be useful here. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions 2020-06-10 7:43 ` Will Deacon @ 2020-06-11 15:46 ` Achin Gupta -1 siblings, 0 replies; 45+ messages in thread From: Achin Gupta @ 2020-06-11 15:46 UTC (permalink / raw) To: Will Deacon Cc: Rob Herring, Sudeep Holla, devicetree, linux-arm-kernel, linux-kernel, Marc Zyngier, nd Hi Will, > On 10 Jun 2020, at 08:43, Will Deacon <will@kernel.org> wrote: > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: >> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: >>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition >>> at virtual interface(VMs). >>> >>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> >>> --- >>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ >>> 1 file changed, 47 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt >> >> I'm hoping this goes away if the firmware is discoverable, but if not DT >> bindings are DT schema now. > > We'll need the binding for the kvm host side, because there are plenty > of partition properties that are not discoverable (e.g. number of vCPUs). Just trying to understand the req. a bit better… The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine the count of partitions and their vCPUs. Is this about a guest being able to find out how many vCPUs it has? Cheers, Achin > > I'll have a go a yamlifying what I have... > > Will > ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions @ 2020-06-11 15:46 ` Achin Gupta 0 siblings, 0 replies; 45+ messages in thread From: Achin Gupta @ 2020-06-11 15:46 UTC (permalink / raw) To: Will Deacon Cc: Rob Herring, devicetree, Marc Zyngier, linux-kernel, Sudeep Holla, nd, linux-arm-kernel Hi Will, > On 10 Jun 2020, at 08:43, Will Deacon <will@kernel.org> wrote: > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: >> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: >>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition >>> at virtual interface(VMs). >>> >>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> >>> --- >>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ >>> 1 file changed, 47 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt >> >> I'm hoping this goes away if the firmware is discoverable, but if not DT >> bindings are DT schema now. > > We'll need the binding for the kvm host side, because there are plenty > of partition properties that are not discoverable (e.g. number of vCPUs). Just trying to understand the req. a bit better… The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine the count of partitions and their vCPUs. Is this about a guest being able to find out how many vCPUs it has? Cheers, Achin > > I'll have a go a yamlifying what I have... > > Will > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions 2020-06-11 15:46 ` Achin Gupta @ 2020-06-11 17:12 ` Will Deacon -1 siblings, 0 replies; 45+ messages in thread From: Will Deacon @ 2020-06-11 17:12 UTC (permalink / raw) To: Achin Gupta Cc: Rob Herring, Sudeep Holla, devicetree, linux-arm-kernel, linux-kernel, Marc Zyngier, nd On Thu, Jun 11, 2020 at 03:46:35PM +0000, Achin Gupta wrote: > > On 10 Jun 2020, at 08:43, Will Deacon <will@kernel.org> wrote: > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > >> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > >>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > >>> at virtual interface(VMs). > >>> > >>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > >>> --- > >>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > >>> 1 file changed, 47 insertions(+) > >>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > >> > >> I'm hoping this goes away if the firmware is discoverable, but if not DT > >> bindings are DT schema now. > > > > We'll need the binding for the kvm host side, because there are plenty > > of partition properties that are not discoverable (e.g. number of vCPUs). > > Just trying to understand the req. a bit better… > > The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine > the count of partitions and their vCPUs. > > Is this about a guest being able to find out how many vCPUs it has? This is about KVM finding out the information it needs in order to spawn non-secure partitions. I don't see how it can do that with FFA_PARTITION_INFO_GET -- who would respond? But you're right that number of vCPUs was a bad example. We also need information such as the entry point. Will ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions @ 2020-06-11 17:12 ` Will Deacon 0 siblings, 0 replies; 45+ messages in thread From: Will Deacon @ 2020-06-11 17:12 UTC (permalink / raw) To: Achin Gupta Cc: Rob Herring, devicetree, Marc Zyngier, linux-kernel, Sudeep Holla, nd, linux-arm-kernel On Thu, Jun 11, 2020 at 03:46:35PM +0000, Achin Gupta wrote: > > On 10 Jun 2020, at 08:43, Will Deacon <will@kernel.org> wrote: > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > >> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > >>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > >>> at virtual interface(VMs). > >>> > >>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > >>> --- > >>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > >>> 1 file changed, 47 insertions(+) > >>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > >> > >> I'm hoping this goes away if the firmware is discoverable, but if not DT > >> bindings are DT schema now. > > > > We'll need the binding for the kvm host side, because there are plenty > > of partition properties that are not discoverable (e.g. number of vCPUs). > > Just trying to understand the req. a bit better… > > The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine > the count of partitions and their vCPUs. > > Is this about a guest being able to find out how many vCPUs it has? This is about KVM finding out the information it needs in order to spawn non-secure partitions. I don't see how it can do that with FFA_PARTITION_INFO_GET -- who would respond? But you're right that number of vCPUs was a bad example. We also need information such as the entry point. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions 2020-06-11 17:12 ` Will Deacon @ 2020-06-15 9:16 ` Achin Gupta -1 siblings, 0 replies; 45+ messages in thread From: Achin Gupta @ 2020-06-15 9:16 UTC (permalink / raw) To: Will Deacon Cc: Rob Herring, Sudeep Holla, devicetree, linux-arm-kernel, linux-kernel, Marc Zyngier, nd On Thu, Jun 11, 2020 at 06:12:23PM +0100, Will Deacon wrote: > On Thu, Jun 11, 2020 at 03:46:35PM +0000, Achin Gupta wrote: > > > On 10 Jun 2020, at 08:43, Will Deacon <will@kernel.org> wrote: > > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > > >> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > > >>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > > >>> at virtual interface(VMs). > > >>> > > >>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > >>> --- > > >>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > > >>> 1 file changed, 47 insertions(+) > > >>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > > >> > > >> I'm hoping this goes away if the firmware is discoverable, but if not DT > > >> bindings are DT schema now. > > > > > > We'll need the binding for the kvm host side, because there are plenty > > > of partition properties that are not discoverable (e.g. number of vCPUs). > > > > Just trying to understand the req. a bit better… > > > > The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine > > the count of partitions and their vCPUs. > > > > Is this about a guest being able to find out how many vCPUs it has? > > This is about KVM finding out the information it needs in order to spawn > non-secure partitions. I don't see how it can do that with > FFA_PARTITION_INFO_GET -- who would respond? Right! FFA_PARTITION_INFO_GET is meant to help the FF-A driver in the kernel to determine partition properties. It assumes that EL2 SW has already read each partition's manifest and will reply to this ABI. IIUC, with protected KVM, this information will have to be a part of the manifest that the KVM host consumes. But then, can this be made discoverable (use a SMC for discovery) at all as Rob had originally suggested. Firmware (Secure world) has no clue and the bootloader is long gone. Separate topic, protected KVM does not get dibs on the manifest and it relies on the KVM host to specify the address ranges for each partition? Does this not mean that the KVM host can control the physical address space each partition sees. This seems contrary to the isolation guarantees that protected KVM must provide? > > But you're right that number of vCPUs was a bad example. We also need > information such as the entry point. Yes. From a spec perspective this should be specified in the partition manifest unless the base address of the loaded image can be assummed to be the entry point. cheers, Achin > > Will ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions @ 2020-06-15 9:16 ` Achin Gupta 0 siblings, 0 replies; 45+ messages in thread From: Achin Gupta @ 2020-06-15 9:16 UTC (permalink / raw) To: Will Deacon Cc: Rob Herring, devicetree, Marc Zyngier, linux-kernel, Sudeep Holla, nd, linux-arm-kernel On Thu, Jun 11, 2020 at 06:12:23PM +0100, Will Deacon wrote: > On Thu, Jun 11, 2020 at 03:46:35PM +0000, Achin Gupta wrote: > > > On 10 Jun 2020, at 08:43, Will Deacon <will@kernel.org> wrote: > > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > > >> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > > >>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > > >>> at virtual interface(VMs). > > >>> > > >>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > >>> --- > > >>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > > >>> 1 file changed, 47 insertions(+) > > >>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > > >> > > >> I'm hoping this goes away if the firmware is discoverable, but if not DT > > >> bindings are DT schema now. > > > > > > We'll need the binding for the kvm host side, because there are plenty > > > of partition properties that are not discoverable (e.g. number of vCPUs). > > > > Just trying to understand the req. a bit better… > > > > The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine > > the count of partitions and their vCPUs. > > > > Is this about a guest being able to find out how many vCPUs it has? > > This is about KVM finding out the information it needs in order to spawn > non-secure partitions. I don't see how it can do that with > FFA_PARTITION_INFO_GET -- who would respond? Right! FFA_PARTITION_INFO_GET is meant to help the FF-A driver in the kernel to determine partition properties. It assumes that EL2 SW has already read each partition's manifest and will reply to this ABI. IIUC, with protected KVM, this information will have to be a part of the manifest that the KVM host consumes. But then, can this be made discoverable (use a SMC for discovery) at all as Rob had originally suggested. Firmware (Secure world) has no clue and the bootloader is long gone. Separate topic, protected KVM does not get dibs on the manifest and it relies on the KVM host to specify the address ranges for each partition? Does this not mean that the KVM host can control the physical address space each partition sees. This seems contrary to the isolation guarantees that protected KVM must provide? > > But you're right that number of vCPUs was a bad example. We also need > information such as the entry point. Yes. From a spec perspective this should be specified in the partition manifest unless the base address of the loaded image can be assummed to be the entry point. cheers, Achin > > Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions 2020-06-15 9:16 ` Achin Gupta @ 2020-06-15 9:51 ` Will Deacon -1 siblings, 0 replies; 45+ messages in thread From: Will Deacon @ 2020-06-15 9:51 UTC (permalink / raw) To: Achin Gupta Cc: Rob Herring, Sudeep Holla, devicetree, linux-arm-kernel, linux-kernel, Marc Zyngier, nd On Mon, Jun 15, 2020 at 10:16:39AM +0100, Achin Gupta wrote: > On Thu, Jun 11, 2020 at 06:12:23PM +0100, Will Deacon wrote: > > On Thu, Jun 11, 2020 at 03:46:35PM +0000, Achin Gupta wrote: > > > > On 10 Jun 2020, at 08:43, Will Deacon <will@kernel.org> wrote: > > > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > > > >> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > > > >>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > > > >>> at virtual interface(VMs). > > > >>> > > > >>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > >>> --- > > > >>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > > > >>> 1 file changed, 47 insertions(+) > > > >>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > > > >> > > > >> I'm hoping this goes away if the firmware is discoverable, but if not DT > > > >> bindings are DT schema now. > > > > > > > > We'll need the binding for the kvm host side, because there are plenty > > > > of partition properties that are not discoverable (e.g. number of vCPUs). > > > > > > Just trying to understand the req. a bit better… > > > > > > The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine > > > the count of partitions and their vCPUs. > > > > > > Is this about a guest being able to find out how many vCPUs it has? > > > > This is about KVM finding out the information it needs in order to spawn > > non-secure partitions. I don't see how it can do that with > > FFA_PARTITION_INFO_GET -- who would respond? > > Right! FFA_PARTITION_INFO_GET is meant to help the FF-A driver in the kernel to > determine partition properties. It assumes that EL2 SW has already read each > partition's manifest and will reply to this ABI. > > IIUC, with protected KVM, this information will have to be a part of the > manifest that the KVM host consumes. The host does not consume the manifest directly -- instead, the bootloader will use the manifest to populate these DT nodes. Again, these are *only* for non-secure virtual partitions which are to be managed by KVM. > But then, can this be made discoverable (use a SMC for discovery) at all as Rob > had originally suggested. Firmware (Secure world) has no clue and the bootloader > is long gone. Make what discoverable? > Separate topic, protected KVM does not get dibs on the manifest and it relies on > the KVM host to specify the address ranges for each partition? Does this not > mean that the KVM host can control the physical address space each partition > sees. This seems contrary to the isolation guarantees that protected KVM must > provide? The host is trusted during early boot, and gives up this trust after initialising EL2 fully. So roughly speaking, we: * Boot at EL2 and install a shim * Drop down to EL2 and start the host kernel * Before some initialisation (DT parsing, SMP bringup, etc) * Init KVM by calling back up to EL2 to install the full hypervisor At that point, the EL1 host is no longer trusted and the last call effectively "locks it out" from EL2. > > But you're right that number of vCPUs was a bad example. We also need > > information such as the entry point. > > Yes. From a spec perspective this should be specified in the partition manifest > unless the base address of the loaded image can be assummed to be the entry > point. Right, but the format of the manifest isn't defined by the spec so I really don't think it's something that Linux should be dealing with directly. Will ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions @ 2020-06-15 9:51 ` Will Deacon 0 siblings, 0 replies; 45+ messages in thread From: Will Deacon @ 2020-06-15 9:51 UTC (permalink / raw) To: Achin Gupta Cc: Rob Herring, devicetree, Marc Zyngier, linux-kernel, Sudeep Holla, nd, linux-arm-kernel On Mon, Jun 15, 2020 at 10:16:39AM +0100, Achin Gupta wrote: > On Thu, Jun 11, 2020 at 06:12:23PM +0100, Will Deacon wrote: > > On Thu, Jun 11, 2020 at 03:46:35PM +0000, Achin Gupta wrote: > > > > On 10 Jun 2020, at 08:43, Will Deacon <will@kernel.org> wrote: > > > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > > > >> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > > > >>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > > > >>> at virtual interface(VMs). > > > >>> > > > >>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > >>> --- > > > >>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > > > >>> 1 file changed, 47 insertions(+) > > > >>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > > > >> > > > >> I'm hoping this goes away if the firmware is discoverable, but if not DT > > > >> bindings are DT schema now. > > > > > > > > We'll need the binding for the kvm host side, because there are plenty > > > > of partition properties that are not discoverable (e.g. number of vCPUs). > > > > > > Just trying to understand the req. a bit better… > > > > > > The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine > > > the count of partitions and their vCPUs. > > > > > > Is this about a guest being able to find out how many vCPUs it has? > > > > This is about KVM finding out the information it needs in order to spawn > > non-secure partitions. I don't see how it can do that with > > FFA_PARTITION_INFO_GET -- who would respond? > > Right! FFA_PARTITION_INFO_GET is meant to help the FF-A driver in the kernel to > determine partition properties. It assumes that EL2 SW has already read each > partition's manifest and will reply to this ABI. > > IIUC, with protected KVM, this information will have to be a part of the > manifest that the KVM host consumes. The host does not consume the manifest directly -- instead, the bootloader will use the manifest to populate these DT nodes. Again, these are *only* for non-secure virtual partitions which are to be managed by KVM. > But then, can this be made discoverable (use a SMC for discovery) at all as Rob > had originally suggested. Firmware (Secure world) has no clue and the bootloader > is long gone. Make what discoverable? > Separate topic, protected KVM does not get dibs on the manifest and it relies on > the KVM host to specify the address ranges for each partition? Does this not > mean that the KVM host can control the physical address space each partition > sees. This seems contrary to the isolation guarantees that protected KVM must > provide? The host is trusted during early boot, and gives up this trust after initialising EL2 fully. So roughly speaking, we: * Boot at EL2 and install a shim * Drop down to EL2 and start the host kernel * Before some initialisation (DT parsing, SMP bringup, etc) * Init KVM by calling back up to EL2 to install the full hypervisor At that point, the EL1 host is no longer trusted and the last call effectively "locks it out" from EL2. > > But you're right that number of vCPUs was a bad example. We also need > > information such as the entry point. > > Yes. From a spec perspective this should be specified in the partition manifest > unless the base address of the loaded image can be assummed to be the entry > point. Right, but the format of the manifest isn't defined by the spec so I really don't think it's something that Linux should be dealing with directly. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions 2020-06-15 9:51 ` Will Deacon @ 2020-06-15 11:42 ` Achin Gupta -1 siblings, 0 replies; 45+ messages in thread From: Achin Gupta @ 2020-06-15 11:42 UTC (permalink / raw) To: Will Deacon Cc: Rob Herring, Sudeep Holla, devicetree, linux-arm-kernel, linux-kernel, Marc Zyngier, nd On Mon, Jun 15, 2020 at 10:51:34AM +0100, Will Deacon wrote: > On Mon, Jun 15, 2020 at 10:16:39AM +0100, Achin Gupta wrote: > > On Thu, Jun 11, 2020 at 06:12:23PM +0100, Will Deacon wrote: > > > On Thu, Jun 11, 2020 at 03:46:35PM +0000, Achin Gupta wrote: > > > > > On 10 Jun 2020, at 08:43, Will Deacon <will@kernel.org> wrote: > > > > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > > > > >> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > > > > >>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > > > > >>> at virtual interface(VMs). > > > > >>> > > > > >>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > > >>> --- > > > > >>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > > > > >>> 1 file changed, 47 insertions(+) > > > > >>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > > > > >> > > > > >> I'm hoping this goes away if the firmware is discoverable, but if not DT > > > > >> bindings are DT schema now. > > > > > > > > > > We'll need the binding for the kvm host side, because there are plenty > > > > > of partition properties that are not discoverable (e.g. number of vCPUs). > > > > > > > > Just trying to understand the req. a bit better… > > > > > > > > The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine > > > > the count of partitions and their vCPUs. > > > > > > > > Is this about a guest being able to find out how many vCPUs it has? > > > > > > This is about KVM finding out the information it needs in order to spawn > > > non-secure partitions. I don't see how it can do that with > > > FFA_PARTITION_INFO_GET -- who would respond? > > > > Right! FFA_PARTITION_INFO_GET is meant to help the FF-A driver in the kernel to > > determine partition properties. It assumes that EL2 SW has already read each > > partition's manifest and will reply to this ABI. > > > > IIUC, with protected KVM, this information will have to be a part of the > > manifest that the KVM host consumes. > > The host does not consume the manifest directly -- instead, the bootloader > will use the manifest to populate these DT nodes. Again, these are *only* > for non-secure virtual partitions which are to be managed by KVM. Yes. Understand and agree. Manifest is an overloaded term. I was using it to describe the DT nodes that the host will consume. > > > But then, can this be made discoverable (use a SMC for discovery) at all as Rob > > had originally suggested. Firmware (Secure world) has no clue and the bootloader > > is long gone. > > Make what discoverable? I thought the original question was to make partition properties discoverable instead of relying on DT nodes. I might have misunderstood. Looks like we are on the same page in any case :o) > > > Separate topic, protected KVM does not get dibs on the manifest and it relies on > > the KVM host to specify the address ranges for each partition? Does this not > > mean that the KVM host can control the physical address space each partition > > sees. This seems contrary to the isolation guarantees that protected KVM must > > provide? > > The host is trusted during early boot, and gives up this trust after > initialising EL2 fully. So roughly speaking, we: > > * Boot at EL2 and install a shim > * Drop down to EL2 and start the host kernel > * Before some initialisation (DT parsing, SMP bringup, etc) > * Init KVM by calling back up to EL2 to install the full hypervisor > > At that point, the EL1 host is no longer trusted and the last call > effectively "locks it out" from EL2. Ok. Protected KVM (PKVM) must create S2 tables when asked to setup a partition by the Host. My main concern is if PKVM must trust the Host to provide the correct physical address space ranges for a partition? I guess your point is this is not a problem since PKVM can lock the Host out of those address ranges in any case? It is a bit counter intuitive that the Host gets to see and potentially manipulate information that was verified and extracted by the bootloader from the partition's manifest. This hapens before PKVM sees the same information. Can't put my finger on what could go wrong though. Depends upon the threat model too! > > > > But you're right that number of vCPUs was a bad example. We also need > > > information such as the entry point. > > > > Yes. From a spec perspective this should be specified in the partition manifest > > unless the base address of the loaded image can be assummed to be the entry > > point. > > Right, but the format of the manifest isn't defined by the spec so I really > don't think it's something that Linux should be dealing with directly. Agree. cheers, Achin > > Will ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions @ 2020-06-15 11:42 ` Achin Gupta 0 siblings, 0 replies; 45+ messages in thread From: Achin Gupta @ 2020-06-15 11:42 UTC (permalink / raw) To: Will Deacon Cc: Rob Herring, devicetree, Marc Zyngier, linux-kernel, Sudeep Holla, nd, linux-arm-kernel On Mon, Jun 15, 2020 at 10:51:34AM +0100, Will Deacon wrote: > On Mon, Jun 15, 2020 at 10:16:39AM +0100, Achin Gupta wrote: > > On Thu, Jun 11, 2020 at 06:12:23PM +0100, Will Deacon wrote: > > > On Thu, Jun 11, 2020 at 03:46:35PM +0000, Achin Gupta wrote: > > > > > On 10 Jun 2020, at 08:43, Will Deacon <will@kernel.org> wrote: > > > > > On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > > > > >> On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > > > > >>> Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > > > > >>> at virtual interface(VMs). > > > > >>> > > > > >>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > > > >>> --- > > > > >>> .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > > > > >>> 1 file changed, 47 insertions(+) > > > > >>> create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > > > > >> > > > > >> I'm hoping this goes away if the firmware is discoverable, but if not DT > > > > >> bindings are DT schema now. > > > > > > > > > > We'll need the binding for the kvm host side, because there are plenty > > > > > of partition properties that are not discoverable (e.g. number of vCPUs). > > > > > > > > Just trying to understand the req. a bit better… > > > > > > > > The FF-A driver in the host can use FFA_PARTITION_INFO_GET to determine > > > > the count of partitions and their vCPUs. > > > > > > > > Is this about a guest being able to find out how many vCPUs it has? > > > > > > This is about KVM finding out the information it needs in order to spawn > > > non-secure partitions. I don't see how it can do that with > > > FFA_PARTITION_INFO_GET -- who would respond? > > > > Right! FFA_PARTITION_INFO_GET is meant to help the FF-A driver in the kernel to > > determine partition properties. It assumes that EL2 SW has already read each > > partition's manifest and will reply to this ABI. > > > > IIUC, with protected KVM, this information will have to be a part of the > > manifest that the KVM host consumes. > > The host does not consume the manifest directly -- instead, the bootloader > will use the manifest to populate these DT nodes. Again, these are *only* > for non-secure virtual partitions which are to be managed by KVM. Yes. Understand and agree. Manifest is an overloaded term. I was using it to describe the DT nodes that the host will consume. > > > But then, can this be made discoverable (use a SMC for discovery) at all as Rob > > had originally suggested. Firmware (Secure world) has no clue and the bootloader > > is long gone. > > Make what discoverable? I thought the original question was to make partition properties discoverable instead of relying on DT nodes. I might have misunderstood. Looks like we are on the same page in any case :o) > > > Separate topic, protected KVM does not get dibs on the manifest and it relies on > > the KVM host to specify the address ranges for each partition? Does this not > > mean that the KVM host can control the physical address space each partition > > sees. This seems contrary to the isolation guarantees that protected KVM must > > provide? > > The host is trusted during early boot, and gives up this trust after > initialising EL2 fully. So roughly speaking, we: > > * Boot at EL2 and install a shim > * Drop down to EL2 and start the host kernel > * Before some initialisation (DT parsing, SMP bringup, etc) > * Init KVM by calling back up to EL2 to install the full hypervisor > > At that point, the EL1 host is no longer trusted and the last call > effectively "locks it out" from EL2. Ok. Protected KVM (PKVM) must create S2 tables when asked to setup a partition by the Host. My main concern is if PKVM must trust the Host to provide the correct physical address space ranges for a partition? I guess your point is this is not a problem since PKVM can lock the Host out of those address ranges in any case? It is a bit counter intuitive that the Host gets to see and potentially manipulate information that was verified and extracted by the bootloader from the partition's manifest. This hapens before PKVM sees the same information. Can't put my finger on what could go wrong though. Depends upon the threat model too! > > > > But you're right that number of vCPUs was a bad example. We also need > > > information such as the entry point. > > > > Yes. From a spec perspective this should be specified in the partition manifest > > unless the base address of the loaded image can be assummed to be the entry > > point. > > Right, but the format of the manifest isn't defined by the spec so I really > don't think it's something that Linux should be dealing with directly. Agree. cheers, Achin > > Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions 2020-06-15 11:42 ` Achin Gupta @ 2020-06-15 11:55 ` Will Deacon -1 siblings, 0 replies; 45+ messages in thread From: Will Deacon @ 2020-06-15 11:55 UTC (permalink / raw) To: Achin Gupta Cc: Rob Herring, Sudeep Holla, devicetree, linux-arm-kernel, linux-kernel, Marc Zyngier, nd On Mon, Jun 15, 2020 at 12:42:20PM +0100, Achin Gupta wrote: > On Mon, Jun 15, 2020 at 10:51:34AM +0100, Will Deacon wrote: > > On Mon, Jun 15, 2020 at 10:16:39AM +0100, Achin Gupta wrote: > > > Right! FFA_PARTITION_INFO_GET is meant to help the FF-A driver in the kernel to > > > determine partition properties. It assumes that EL2 SW has already read each > > > partition's manifest and will reply to this ABI. > > > > > > IIUC, with protected KVM, this information will have to be a part of the > > > manifest that the KVM host consumes. > > > > The host does not consume the manifest directly -- instead, the bootloader > > will use the manifest to populate these DT nodes. Again, these are *only* > > for non-secure virtual partitions which are to be managed by KVM. > > Yes. Understand and agree. Manifest is an overloaded term. I was using it to > describe the DT nodes that the host will consume. Hmm, I think that conflates two things though because only the partitions managed by KVM will have DT nodes. > > > Separate topic, protected KVM does not get dibs on the manifest and it relies on > > > the KVM host to specify the address ranges for each partition? Does this not > > > mean that the KVM host can control the physical address space each partition > > > sees. This seems contrary to the isolation guarantees that protected KVM must > > > provide? > > > > The host is trusted during early boot, and gives up this trust after > > initialising EL2 fully. So roughly speaking, we: > > > > * Boot at EL2 and install a shim > > * Drop down to EL2 and start the host kernel > > * Before some initialisation (DT parsing, SMP bringup, etc) > > * Init KVM by calling back up to EL2 to install the full hypervisor > > > > At that point, the EL1 host is no longer trusted and the last call > > effectively "locks it out" from EL2. > > Ok. Protected KVM (PKVM) must create S2 tables when asked to setup a partition > by the Host. My main concern is if PKVM must trust the Host to provide the > correct physical address space ranges for a partition? Yes, but that all happens as part of KVM initialisation: the host parses the DT nodes and memory reservations, and then passes this information up to EL2. > I guess your point is this is not a problem since PKVM can lock the Host out of > those address ranges in any case? It has to do this, regardless of how they are probed. Once KVM has initialised, the host will have a stage-2 which limits it to the memory that it is allowed to access. > It is a bit counter intuitive that the Host gets to see and potentially > manipulate information that was verified and extracted by the bootloader from > the partition's manifest. This hapens before PKVM sees the same > information. Can't put my finger on what could go wrong though. Depends upon the > threat model too! I think you're trying too hard to separate the host from the EL2 code during early boot. Don't forget -- this is all part of the same binary payload that is loaded and initially run at EL2. Having the host take care of early boot /significantly/ reduces the amount of code at EL2, which has a very clear security benefit. Will ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions @ 2020-06-15 11:55 ` Will Deacon 0 siblings, 0 replies; 45+ messages in thread From: Will Deacon @ 2020-06-15 11:55 UTC (permalink / raw) To: Achin Gupta Cc: Rob Herring, devicetree, Marc Zyngier, linux-kernel, Sudeep Holla, nd, linux-arm-kernel On Mon, Jun 15, 2020 at 12:42:20PM +0100, Achin Gupta wrote: > On Mon, Jun 15, 2020 at 10:51:34AM +0100, Will Deacon wrote: > > On Mon, Jun 15, 2020 at 10:16:39AM +0100, Achin Gupta wrote: > > > Right! FFA_PARTITION_INFO_GET is meant to help the FF-A driver in the kernel to > > > determine partition properties. It assumes that EL2 SW has already read each > > > partition's manifest and will reply to this ABI. > > > > > > IIUC, with protected KVM, this information will have to be a part of the > > > manifest that the KVM host consumes. > > > > The host does not consume the manifest directly -- instead, the bootloader > > will use the manifest to populate these DT nodes. Again, these are *only* > > for non-secure virtual partitions which are to be managed by KVM. > > Yes. Understand and agree. Manifest is an overloaded term. I was using it to > describe the DT nodes that the host will consume. Hmm, I think that conflates two things though because only the partitions managed by KVM will have DT nodes. > > > Separate topic, protected KVM does not get dibs on the manifest and it relies on > > > the KVM host to specify the address ranges for each partition? Does this not > > > mean that the KVM host can control the physical address space each partition > > > sees. This seems contrary to the isolation guarantees that protected KVM must > > > provide? > > > > The host is trusted during early boot, and gives up this trust after > > initialising EL2 fully. So roughly speaking, we: > > > > * Boot at EL2 and install a shim > > * Drop down to EL2 and start the host kernel > > * Before some initialisation (DT parsing, SMP bringup, etc) > > * Init KVM by calling back up to EL2 to install the full hypervisor > > > > At that point, the EL1 host is no longer trusted and the last call > > effectively "locks it out" from EL2. > > Ok. Protected KVM (PKVM) must create S2 tables when asked to setup a partition > by the Host. My main concern is if PKVM must trust the Host to provide the > correct physical address space ranges for a partition? Yes, but that all happens as part of KVM initialisation: the host parses the DT nodes and memory reservations, and then passes this information up to EL2. > I guess your point is this is not a problem since PKVM can lock the Host out of > those address ranges in any case? It has to do this, regardless of how they are probed. Once KVM has initialised, the host will have a stage-2 which limits it to the memory that it is allowed to access. > It is a bit counter intuitive that the Host gets to see and potentially > manipulate information that was verified and extracted by the bootloader from > the partition's manifest. This hapens before PKVM sees the same > information. Can't put my finger on what could go wrong though. Depends upon the > threat model too! I think you're trying too hard to separate the host from the EL2 code during early boot. Don't forget -- this is all part of the same binary payload that is loaded and initially run at EL2. Having the host take care of early boot /significantly/ reduces the amount of code at EL2, which has a very clear security benefit. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions 2020-06-15 11:55 ` Will Deacon @ 2020-06-15 16:48 ` Achin Gupta -1 siblings, 0 replies; 45+ messages in thread From: Achin Gupta @ 2020-06-15 16:48 UTC (permalink / raw) To: Will Deacon Cc: Rob Herring, Sudeep Holla, devicetree, linux-arm-kernel, linux-kernel, Marc Zyngier, nd On Mon, Jun 15, 2020 at 12:55:49PM +0100, Will Deacon wrote: > On Mon, Jun 15, 2020 at 12:42:20PM +0100, Achin Gupta wrote: > > On Mon, Jun 15, 2020 at 10:51:34AM +0100, Will Deacon wrote: > > > On Mon, Jun 15, 2020 at 10:16:39AM +0100, Achin Gupta wrote: > > > > Right! FFA_PARTITION_INFO_GET is meant to help the FF-A driver in the kernel to > > > > determine partition properties. It assumes that EL2 SW has already read each > > > > partition's manifest and will reply to this ABI. > > > > > > > > IIUC, with protected KVM, this information will have to be a part of the > > > > manifest that the KVM host consumes. > > > > > > The host does not consume the manifest directly -- instead, the bootloader > > > will use the manifest to populate these DT nodes. Again, these are *only* > > > for non-secure virtual partitions which are to be managed by KVM. > > > > Yes. Understand and agree. Manifest is an overloaded term. I was using it to > > describe the DT nodes that the host will consume. > > Hmm, I think that conflates two things though because only the partitions > managed by KVM will have DT nodes. Sure. I am realising the need to maintain the distinction :o) > > > > > Separate topic, protected KVM does not get dibs on the manifest and it relies on > > > > the KVM host to specify the address ranges for each partition? Does this not > > > > mean that the KVM host can control the physical address space each partition > > > > sees. This seems contrary to the isolation guarantees that protected KVM must > > > > provide? > > > > > > The host is trusted during early boot, and gives up this trust after > > > initialising EL2 fully. So roughly speaking, we: > > > > > > * Boot at EL2 and install a shim > > > * Drop down to EL2 and start the host kernel > > > * Before some initialisation (DT parsing, SMP bringup, etc) > > > * Init KVM by calling back up to EL2 to install the full hypervisor > > > > > > At that point, the EL1 host is no longer trusted and the last call > > > effectively "locks it out" from EL2. > > > > Ok. Protected KVM (PKVM) must create S2 tables when asked to setup a partition > > by the Host. My main concern is if PKVM must trust the Host to provide the > > correct physical address space ranges for a partition? > > Yes, but that all happens as part of KVM initialisation: the host parses > the DT nodes and memory reservations, and then passes this information > up to EL2. Ok. Good to know this. > > > I guess your point is this is not a problem since PKVM can lock the Host out of > > those address ranges in any case? > > It has to do this, regardless of how they are probed. Once KVM has > initialised, the host will have a stage-2 which limits it to the memory that > it is allowed to access. Agree. > > > It is a bit counter intuitive that the Host gets to see and potentially > > manipulate information that was verified and extracted by the bootloader from > > the partition's manifest. This hapens before PKVM sees the same > > information. Can't put my finger on what could go wrong though. Depends upon the > > threat model too! > > I think you're trying too hard to separate the host from the EL2 code during > early boot. Don't forget -- this is all part of the same binary payload that > is loaded and initially run at EL2. Having the host take care of early boot > /significantly/ reduces the amount of code at EL2, which has a very > clear security benefit. Fair point! cheers, Achin > > Will ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions @ 2020-06-15 16:48 ` Achin Gupta 0 siblings, 0 replies; 45+ messages in thread From: Achin Gupta @ 2020-06-15 16:48 UTC (permalink / raw) To: Will Deacon Cc: Rob Herring, devicetree, Marc Zyngier, linux-kernel, Sudeep Holla, nd, linux-arm-kernel On Mon, Jun 15, 2020 at 12:55:49PM +0100, Will Deacon wrote: > On Mon, Jun 15, 2020 at 12:42:20PM +0100, Achin Gupta wrote: > > On Mon, Jun 15, 2020 at 10:51:34AM +0100, Will Deacon wrote: > > > On Mon, Jun 15, 2020 at 10:16:39AM +0100, Achin Gupta wrote: > > > > Right! FFA_PARTITION_INFO_GET is meant to help the FF-A driver in the kernel to > > > > determine partition properties. It assumes that EL2 SW has already read each > > > > partition's manifest and will reply to this ABI. > > > > > > > > IIUC, with protected KVM, this information will have to be a part of the > > > > manifest that the KVM host consumes. > > > > > > The host does not consume the manifest directly -- instead, the bootloader > > > will use the manifest to populate these DT nodes. Again, these are *only* > > > for non-secure virtual partitions which are to be managed by KVM. > > > > Yes. Understand and agree. Manifest is an overloaded term. I was using it to > > describe the DT nodes that the host will consume. > > Hmm, I think that conflates two things though because only the partitions > managed by KVM will have DT nodes. Sure. I am realising the need to maintain the distinction :o) > > > > > Separate topic, protected KVM does not get dibs on the manifest and it relies on > > > > the KVM host to specify the address ranges for each partition? Does this not > > > > mean that the KVM host can control the physical address space each partition > > > > sees. This seems contrary to the isolation guarantees that protected KVM must > > > > provide? > > > > > > The host is trusted during early boot, and gives up this trust after > > > initialising EL2 fully. So roughly speaking, we: > > > > > > * Boot at EL2 and install a shim > > > * Drop down to EL2 and start the host kernel > > > * Before some initialisation (DT parsing, SMP bringup, etc) > > > * Init KVM by calling back up to EL2 to install the full hypervisor > > > > > > At that point, the EL1 host is no longer trusted and the last call > > > effectively "locks it out" from EL2. > > > > Ok. Protected KVM (PKVM) must create S2 tables when asked to setup a partition > > by the Host. My main concern is if PKVM must trust the Host to provide the > > correct physical address space ranges for a partition? > > Yes, but that all happens as part of KVM initialisation: the host parses > the DT nodes and memory reservations, and then passes this information > up to EL2. Ok. Good to know this. > > > I guess your point is this is not a problem since PKVM can lock the Host out of > > those address ranges in any case? > > It has to do this, regardless of how they are probed. Once KVM has > initialised, the host will have a stage-2 which limits it to the memory that > it is allowed to access. Agree. > > > It is a bit counter intuitive that the Host gets to see and potentially > > manipulate information that was verified and extracted by the bootloader from > > the partition's manifest. This hapens before PKVM sees the same > > information. Can't put my finger on what could go wrong though. Depends upon the > > threat model too! > > I think you're trying too hard to separate the host from the EL2 code during > early boot. Don't forget -- this is all part of the same binary payload that > is loaded and initially run at EL2. Having the host take care of early boot > /significantly/ reduces the amount of code at EL2, which has a very > clear security benefit. Fair point! cheers, Achin > > Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions 2020-06-09 22:35 ` Rob Herring @ 2020-06-10 8:32 ` Sudeep Holla -1 siblings, 0 replies; 45+ messages in thread From: Sudeep Holla @ 2020-06-10 8:32 UTC (permalink / raw) To: Rob Herring Cc: Will Deacon, devicetree, linux-arm-kernel, linux-kernel, Marc Zyngier, Sudeep Holla On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > > Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > > at virtual interface(VMs). > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > --- > > .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > > 1 file changed, 47 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > > I'm hoping this goes away if the firmware is discoverable, but if not DT > bindings are DT schema now. > Yes, consider it gone. I introduced it to couple of reasons both of which are now irrelevant. We may revisit this if we need it for Rx/Tx buffer information. The KVM host may need the binding, this was for the guests/ partitions as Will has already mentioned. -- Regards, Sudeep ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions @ 2020-06-10 8:32 ` Sudeep Holla 0 siblings, 0 replies; 45+ messages in thread From: Sudeep Holla @ 2020-06-10 8:32 UTC (permalink / raw) To: Rob Herring Cc: devicetree, Marc Zyngier, linux-kernel, Sudeep Holla, Will Deacon, linux-arm-kernel On Tue, Jun 09, 2020 at 04:35:51PM -0600, Rob Herring wrote: > On Mon, Jun 01, 2020 at 10:45:10AM +0100, Sudeep Holla wrote: > > Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition > > at virtual interface(VMs). > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > --- > > .../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++ > > 1 file changed, 47 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt > > I'm hoping this goes away if the firmware is discoverable, but if not DT > bindings are DT schema now. > Yes, consider it gone. I introduced it to couple of reasons both of which are now irrelevant. We may revisit this if we need it for Rx/Tx buffer information. The KVM host may need the binding, this was for the guests/ partitions as Will has already mentioned. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 45+ messages in thread
* [RFC PATCH 2/3] firmware: Add support for PSA FF-A transport for VM partitions 2020-06-01 9:45 ` Sudeep Holla @ 2020-06-01 9:45 ` Sudeep Holla -1 siblings, 0 replies; 45+ messages in thread From: Sudeep Holla @ 2020-06-01 9:45 UTC (permalink / raw) To: Will Deacon, devicetree, linux-arm-kernel Cc: Sudeep Holla, linux-kernel, Marc Zyngier Initial support for PSA FF-A interface providing APIs for non-secure VM partitions. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> --- drivers/firmware/Kconfig | 1 + drivers/firmware/Makefile | 1 + drivers/firmware/arm_psa_ffa/Kconfig | 15 ++ drivers/firmware/arm_psa_ffa/Makefile | 2 + drivers/firmware/arm_psa_ffa/driver.c | 250 ++++++++++++++++++++++++++ include/linux/arm_psa_ffa.h | 42 +++++ 6 files changed, 311 insertions(+) create mode 100644 drivers/firmware/arm_psa_ffa/Kconfig create mode 100644 drivers/firmware/arm_psa_ffa/Makefile create mode 100644 drivers/firmware/arm_psa_ffa/driver.c create mode 100644 include/linux/arm_psa_ffa.h diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig index 4843e94713a4..1ee421974cba 100644 --- a/drivers/firmware/Kconfig +++ b/drivers/firmware/Kconfig @@ -295,6 +295,7 @@ config TURRIS_MOX_RWTM other manufacturing data and also utilize the Entropy Bit Generator for hardware random number generation. +source "drivers/firmware/arm_psa_ffa/Kconfig" source "drivers/firmware/broadcom/Kconfig" source "drivers/firmware/google/Kconfig" source "drivers/firmware/efi/Kconfig" diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile index 99510be9f5ed..1c0b5f130d7d 100644 --- a/drivers/firmware/Makefile +++ b/drivers/firmware/Makefile @@ -22,6 +22,7 @@ obj-$(CONFIG_TI_SCI_PROTOCOL) += ti_sci.o obj-$(CONFIG_TRUSTED_FOUNDATIONS) += trusted_foundations.o obj-$(CONFIG_TURRIS_MOX_RWTM) += turris-mox-rwtm.o +obj-y += arm_psa_ffa/ obj-$(CONFIG_ARM_SCMI_PROTOCOL) += arm_scmi/ obj-y += broadcom/ obj-y += meson/ diff --git a/drivers/firmware/arm_psa_ffa/Kconfig b/drivers/firmware/arm_psa_ffa/Kconfig new file mode 100644 index 000000000000..ba699ec68ec4 --- /dev/null +++ b/drivers/firmware/arm_psa_ffa/Kconfig @@ -0,0 +1,15 @@ +# SPDX-License-Identifier: GPL-2.0-only +config ARM_PSA_FFA_TRANSPORT + tristate "Arm Platform Security Architecture Firmware Framework for Armv8-A" + depends on ARM64 && HAVE_ARM_SMCCC_DISCOVERY + help + This Firmware Framework(FF) of the Platform Security Architecture + (PSA) for Arm A-profile processors describes interfaces that + standardize communication between the various software images which + includes communication between images in the Secure world and + Normal world. It also leverages the virtualization extension to + isolate software images provided by an ecosystem of vendors from + each other. + + This driver provides interface for all the client drivers making + use of the features offered by ARM PSA-FF-A. diff --git a/drivers/firmware/arm_psa_ffa/Makefile b/drivers/firmware/arm_psa_ffa/Makefile new file mode 100644 index 000000000000..ac0455ff71a4 --- /dev/null +++ b/drivers/firmware/arm_psa_ffa/Makefile @@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0-only +obj-$(CONFIG_ARM_PSA_FFA_TRANSPORT) += driver.o diff --git a/drivers/firmware/arm_psa_ffa/driver.c b/drivers/firmware/arm_psa_ffa/driver.c new file mode 100644 index 000000000000..700bd5850746 --- /dev/null +++ b/drivers/firmware/arm_psa_ffa/driver.c @@ -0,0 +1,250 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Arm Platform Security Architecture(PSA) Firmware Framework for ARMv8-A(FFA) + * interface driver + * + * The Arm PSA FFA specification[1] describes a software architecture to + * leverages the virtualization extension to isolate software images + * provided by an ecosystem of vendors from each other and describes + * interfaces that standardize communication between the various software + * images including communication between images in the Secure world and + * Normal world. Any Hypervisor could use the PSA FFA interfaces to enable + * communication between VMs it manages. + * + * The Hypervisor a.k.a Partition managers in FFA terminology can assign + * system resources(Memory regions, Devices, CPU cycles) to the partitions + * and manage isolation amongst them. + * + * [1] https://developer.arm.com/docs/den0077/latest + * + * Copyright (C) 2020 Arm Ltd. + */ + +#define pr_fmt(fmt) "ARM PSA FF-A: " fmt + +#include <linux/arm_psa_ffa.h> +#include <linux/arm-smccc.h> +#include <linux/bitfield.h> +#include <linux/of_address.h> +#include <linux/of_platform.h> +#include <linux/platform_device.h> +#include <linux/module.h> +#include <linux/types.h> + +#define PSA_FFA_SMC(calling_convention, func_num) \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, (calling_convention), \ + ARM_SMCCC_OWNER_STANDARD, (func_num)) + +#define PSA_FFA_SMC_32(func_num) PSA_FFA_SMC(ARM_SMCCC_SMC_32, (func_num)) +#define PSA_FFA_SMC_64(func_num) PSA_FFA_SMC(ARM_SMCCC_SMC_64, (func_num)) + +#define PSA_FFA_ERROR PSA_FFA_SMC_32(0x60) +#define PSA_FFA_SUCCESS PSA_FFA_SMC_32(0x61) +#define PSA_FFA_INTERRUPT PSA_FFA_SMC_32(0x62) +#define PSA_FFA_VERSION PSA_FFA_SMC_32(0x63) +#define PSA_FFA_FEATURES PSA_FFA_SMC_32(0x64) +#define PSA_FFA_PARTITION_INFO_GET PSA_FFA_SMC_32(0x68) +#define PSA_FFA_ID_GET PSA_FFA_SMC_32(0x69) + +/* PSA_FFA error codes. */ +#define PSA_FFA_RET_SUCCESS (0) +#define PSA_FFA_RET_NOT_SUPPORTED (-1) +#define PSA_FFA_RET_INVALID_PARAMETERS (-2) +#define PSA_FFA_RET_NO_MEMORY (-3) +#define PSA_FFA_RET_BUSY (-4) +#define PSA_FFA_RET_INTERRUPTED (-5) +#define PSA_FFA_RET_DENIED (-6) +#define PSA_FFA_RET_RETRY (-7) +#define PSA_FFA_RET_ABORTED (-8) + +#define MAJOR_VERSION_MASK GENMASK(30, 16) +#define MINOR_VERSION_MASK GENMASK(15, 0) +#define MAJOR_VERSION(x) (u16)(FIELD_GET(MAJOR_VERSION_MASK, (x))) +#define MINOR_VERSION(x) (u16)(FIELD_GET(MINOR_VERSION_MASK, (x))) +#define PACK_VERSION_INFO(major, minor) \ + (FIELD_PREP(MAJOR_VERSION_MASK, (major)) | \ + FIELD_PREP(MINOR_VERSION_MASK, (minor))) +#define PSA_FFA_VERSION_1_0 PACK_VERSION_INFO(1, 0) +#define PSA_FFA_MIN_VERSION PSA_FFA_VERSION_1_0 +#define PSA_FFA_DRIVER_VERSION PSA_FFA_VERSION_1_0 + +#define SENDER_ID_MASK GENMASK(31, 16) +#define RECEIVER_ID_MASK GENMASK(15, 0) +#define SENDER_ID(x) (u16)(FIELD_GET(SENDER_ID_MASK, (x))) +#define RECEIVER_ID(x) (u16)(FIELD_GET(RECEIVER_ID_MASK, (x))) +#define PACK_TARGET_INFO(s, r) \ + (FIELD_PREP(SENDER_ID_MASK, (s)) | FIELD_PREP(RECEIVER_ID_MASK, (r))) + +typedef struct arm_smccc_res +(arm_psa_ffa_fn)(unsigned long, unsigned long, unsigned long, unsigned long, + unsigned long, unsigned long, unsigned long, unsigned long); +static arm_psa_ffa_fn *invoke_arm_psa_ffa_fn; + +static struct device *psa_ffa_dev; + +static const int psa_ffa_linux_errmap[] = { + /* better than switch case as long as return value is continuous */ + 0, /* PSA_FFA_RET_SUCCESS */ + -EOPNOTSUPP, /* PSA_FFA_RET_NOT_SUPPORTED */ + -EINVAL, /* PSA_FFA_RET_INVALID_PARAMETERS */ + -ENOMEM, /* PSA_FFA_RET_NO_MEMORY */ + -EBUSY, /* PSA_FFA_RET_BUSY */ + -EINTR, /* PSA_FFA_RET_INTERRUPTED */ + -EACCES, /* PSA_FFA_RET_DENIED */ + -EAGAIN, /* PSA_FFA_RET_RETRY */ + -ECANCELED, /* PSA_FFA_RET_ABORTED */ +}; + +static inline int psa_ffa_to_linux_errno(int errno) +{ + if (errno < PSA_FFA_RET_SUCCESS && errno >= PSA_FFA_RET_ABORTED) + return psa_ffa_linux_errmap[-errno]; + return -EINVAL; +} + +struct arm_smccc_res +__arm_psa_ffa_fn_smc(unsigned long function_id,unsigned long arg0, + unsigned long arg1, unsigned long arg2, + unsigned long arg3, unsigned long arg4, + unsigned long arg5, unsigned long arg6) +{ + struct arm_smccc_res res; + + arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4, arg5, arg6, + &res); + + return res; +} + +struct arm_smccc_res +__arm_psa_ffa_fn_hvc(unsigned long function_id,unsigned long arg0, + unsigned long arg1, unsigned long arg2, + unsigned long arg3, unsigned long arg4, + unsigned long arg5, unsigned long arg6) +{ + struct arm_smccc_res res; + + arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4, arg5, arg6, + &res); + + return res; +} + +static u16 psa_ffa_id_get(void) +{ + struct arm_smccc_res id; + + id = invoke_arm_psa_ffa_fn(PSA_FFA_ID_GET, 0, 0, 0, 0, 0, 0, 0); + + if (id.a0 == PSA_FFA_ERROR) + return psa_ffa_to_linux_errno((int)id.a2); + else + return id.a2 & 0xffff; +} + +static int psa_ffa_partition_info_get(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3, + struct psa_ffa_partition_info **buffer) +{ + struct arm_smccc_res partition_info; + + partition_info = invoke_arm_psa_ffa_fn(PSA_FFA_PARTITION_INFO_GET, + uuid0, uuid1, uuid2, uuid3, + 0, 0, 0); + + if (partition_info.a0 == PSA_FFA_ERROR) + return psa_ffa_to_linux_errno((int)partition_info.a2); + + /* TODO: read data from RX buffers */ + return partition_info.a2; +} + +static struct arm_psa_ffa_handle drv_handle = { + .id_get = psa_ffa_id_get, + .partition_info_get = psa_ffa_partition_info_get, +}; + +struct arm_psa_ffa_handle *arm_psa_ffa_handle_get(struct device *dev) +{ + struct arm_psa_ffa_handle *handle = NULL; + + if (dev->parent == psa_ffa_dev) + handle = &drv_handle; + + return handle; +} + +EXPORT_SYMBOL_GPL(arm_psa_ffa_handle_get); + +static int psa_ffa_version_check(void) +{ + struct arm_smccc_res version; + + version = invoke_arm_psa_ffa_fn(PSA_FFA_VERSION, PSA_FFA_DRIVER_VERSION, + 0, 0, 0, 0, 0, 0); + + if (version.a0 == PSA_FFA_RET_NOT_SUPPORTED) { + pr_info("PSA_FFA_VERSION returned not supported\n"); + return -ENOTSUPP; + } + + if (version.a0 < PSA_FFA_MIN_VERSION || + version.a0 > PSA_FFA_DRIVER_VERSION) { + pr_err("Incompatible version %d.%d found\n", + MAJOR_VERSION(version.a0), MINOR_VERSION(version.a0)); + return -EINVAL; + } + + pr_info("Found version %d.%d found\n", MAJOR_VERSION(version.a0), + MINOR_VERSION(version.a0)); + return 0; +} + +static int psa_ffa_probe(struct platform_device *pdev) +{ + int ret; + enum arm_smccc_conduit conduit; + + if (arm_smccc_get_version() < ARM_SMCCC_VERSION_1_2) + return 0; + + conduit = arm_smccc_1_1_get_conduit(); + if (conduit == SMCCC_CONDUIT_NONE) { + pr_err("%s: invalid SMCCC conduit\n", __func__); + return -EOPNOTSUPP; + } + + if (conduit == SMCCC_CONDUIT_SMC) + invoke_arm_psa_ffa_fn = __arm_psa_ffa_fn_smc; + else + invoke_arm_psa_ffa_fn = __arm_psa_ffa_fn_hvc; + + ret = psa_ffa_version_check(); + if (ret) + return ret; + + psa_ffa_dev = &pdev->dev; + + return devm_of_platform_populate(psa_ffa_dev); +} + +static const struct of_device_id psa_ffa_of_match[] = { + {.compatible = "arm,psa-ffa"}, + {}, +}; + +MODULE_DEVICE_TABLE(of, psa_ffa_of_match); + +static struct platform_driver psa_ffa_driver = { + .driver = { + .name = "arm-psa-ffa", + .of_match_table = psa_ffa_of_match, + }, + .probe = psa_ffa_probe, +}; + +module_platform_driver(psa_ffa_driver); + +MODULE_ALIAS("platform: arm-psa-ffa"); +MODULE_AUTHOR("Sudeep Holla <sudeep.holla@arm.com>"); +MODULE_DESCRIPTION("Arm PSA FF-A interface driver"); +MODULE_LICENSE("GPL v2"); diff --git a/include/linux/arm_psa_ffa.h b/include/linux/arm_psa_ffa.h new file mode 100644 index 000000000000..03a4ff559fa3 --- /dev/null +++ b/include/linux/arm_psa_ffa.h @@ -0,0 +1,42 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (C) 2019, 2020 Arm Ltd. + */ + +#ifndef __LINUX_ARM_PSA_FFA_H +#define __LINUX_ARM_PSA_FFA_H + +#include <linux/device.h> +#include <linux/types.h> + +struct psa_ffa_partition_info { + /* The ID of the VM the information is about */ + uint16_t id; + /* The number of execution contexts implemented by the partition */ + uint16_t execution_context; + /* The Partition's properties, e.g. supported messaging methods */ + uint32_t partition_properties; +}; + + +/** + * struct psa_ffa_ops - represents the various PSA_FFA protocol operations + * available for an endpoint. + */ +struct arm_psa_ffa_handle { + u16 (*id_get)(void); + int (*partition_info_get)(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3, + struct psa_ffa_partition_info**); +}; + +#if IS_REACHABLE(CONFIG_ARM_PSA_FFA_TRANSPORT) +struct arm_psa_ffa_handle *arm_psa_ffa_handle_get(struct device *dev); +#else +static inline +struct arm_psa_ffa_handle * arm_psa_ffa_handle_get(struct device *dev) +{ + return NULL; +} +#endif + +#endif /*__LINUX_ARM_PSA_FFA_H*/ -- 2.17.1 ^ permalink raw reply related [flat|nested] 45+ messages in thread
* [RFC PATCH 2/3] firmware: Add support for PSA FF-A transport for VM partitions @ 2020-06-01 9:45 ` Sudeep Holla 0 siblings, 0 replies; 45+ messages in thread From: Sudeep Holla @ 2020-06-01 9:45 UTC (permalink / raw) To: Will Deacon, devicetree, linux-arm-kernel Cc: Marc Zyngier, linux-kernel, Sudeep Holla Initial support for PSA FF-A interface providing APIs for non-secure VM partitions. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> --- drivers/firmware/Kconfig | 1 + drivers/firmware/Makefile | 1 + drivers/firmware/arm_psa_ffa/Kconfig | 15 ++ drivers/firmware/arm_psa_ffa/Makefile | 2 + drivers/firmware/arm_psa_ffa/driver.c | 250 ++++++++++++++++++++++++++ include/linux/arm_psa_ffa.h | 42 +++++ 6 files changed, 311 insertions(+) create mode 100644 drivers/firmware/arm_psa_ffa/Kconfig create mode 100644 drivers/firmware/arm_psa_ffa/Makefile create mode 100644 drivers/firmware/arm_psa_ffa/driver.c create mode 100644 include/linux/arm_psa_ffa.h diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig index 4843e94713a4..1ee421974cba 100644 --- a/drivers/firmware/Kconfig +++ b/drivers/firmware/Kconfig @@ -295,6 +295,7 @@ config TURRIS_MOX_RWTM other manufacturing data and also utilize the Entropy Bit Generator for hardware random number generation. +source "drivers/firmware/arm_psa_ffa/Kconfig" source "drivers/firmware/broadcom/Kconfig" source "drivers/firmware/google/Kconfig" source "drivers/firmware/efi/Kconfig" diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile index 99510be9f5ed..1c0b5f130d7d 100644 --- a/drivers/firmware/Makefile +++ b/drivers/firmware/Makefile @@ -22,6 +22,7 @@ obj-$(CONFIG_TI_SCI_PROTOCOL) += ti_sci.o obj-$(CONFIG_TRUSTED_FOUNDATIONS) += trusted_foundations.o obj-$(CONFIG_TURRIS_MOX_RWTM) += turris-mox-rwtm.o +obj-y += arm_psa_ffa/ obj-$(CONFIG_ARM_SCMI_PROTOCOL) += arm_scmi/ obj-y += broadcom/ obj-y += meson/ diff --git a/drivers/firmware/arm_psa_ffa/Kconfig b/drivers/firmware/arm_psa_ffa/Kconfig new file mode 100644 index 000000000000..ba699ec68ec4 --- /dev/null +++ b/drivers/firmware/arm_psa_ffa/Kconfig @@ -0,0 +1,15 @@ +# SPDX-License-Identifier: GPL-2.0-only +config ARM_PSA_FFA_TRANSPORT + tristate "Arm Platform Security Architecture Firmware Framework for Armv8-A" + depends on ARM64 && HAVE_ARM_SMCCC_DISCOVERY + help + This Firmware Framework(FF) of the Platform Security Architecture + (PSA) for Arm A-profile processors describes interfaces that + standardize communication between the various software images which + includes communication between images in the Secure world and + Normal world. It also leverages the virtualization extension to + isolate software images provided by an ecosystem of vendors from + each other. + + This driver provides interface for all the client drivers making + use of the features offered by ARM PSA-FF-A. diff --git a/drivers/firmware/arm_psa_ffa/Makefile b/drivers/firmware/arm_psa_ffa/Makefile new file mode 100644 index 000000000000..ac0455ff71a4 --- /dev/null +++ b/drivers/firmware/arm_psa_ffa/Makefile @@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0-only +obj-$(CONFIG_ARM_PSA_FFA_TRANSPORT) += driver.o diff --git a/drivers/firmware/arm_psa_ffa/driver.c b/drivers/firmware/arm_psa_ffa/driver.c new file mode 100644 index 000000000000..700bd5850746 --- /dev/null +++ b/drivers/firmware/arm_psa_ffa/driver.c @@ -0,0 +1,250 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Arm Platform Security Architecture(PSA) Firmware Framework for ARMv8-A(FFA) + * interface driver + * + * The Arm PSA FFA specification[1] describes a software architecture to + * leverages the virtualization extension to isolate software images + * provided by an ecosystem of vendors from each other and describes + * interfaces that standardize communication between the various software + * images including communication between images in the Secure world and + * Normal world. Any Hypervisor could use the PSA FFA interfaces to enable + * communication between VMs it manages. + * + * The Hypervisor a.k.a Partition managers in FFA terminology can assign + * system resources(Memory regions, Devices, CPU cycles) to the partitions + * and manage isolation amongst them. + * + * [1] https://developer.arm.com/docs/den0077/latest + * + * Copyright (C) 2020 Arm Ltd. + */ + +#define pr_fmt(fmt) "ARM PSA FF-A: " fmt + +#include <linux/arm_psa_ffa.h> +#include <linux/arm-smccc.h> +#include <linux/bitfield.h> +#include <linux/of_address.h> +#include <linux/of_platform.h> +#include <linux/platform_device.h> +#include <linux/module.h> +#include <linux/types.h> + +#define PSA_FFA_SMC(calling_convention, func_num) \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, (calling_convention), \ + ARM_SMCCC_OWNER_STANDARD, (func_num)) + +#define PSA_FFA_SMC_32(func_num) PSA_FFA_SMC(ARM_SMCCC_SMC_32, (func_num)) +#define PSA_FFA_SMC_64(func_num) PSA_FFA_SMC(ARM_SMCCC_SMC_64, (func_num)) + +#define PSA_FFA_ERROR PSA_FFA_SMC_32(0x60) +#define PSA_FFA_SUCCESS PSA_FFA_SMC_32(0x61) +#define PSA_FFA_INTERRUPT PSA_FFA_SMC_32(0x62) +#define PSA_FFA_VERSION PSA_FFA_SMC_32(0x63) +#define PSA_FFA_FEATURES PSA_FFA_SMC_32(0x64) +#define PSA_FFA_PARTITION_INFO_GET PSA_FFA_SMC_32(0x68) +#define PSA_FFA_ID_GET PSA_FFA_SMC_32(0x69) + +/* PSA_FFA error codes. */ +#define PSA_FFA_RET_SUCCESS (0) +#define PSA_FFA_RET_NOT_SUPPORTED (-1) +#define PSA_FFA_RET_INVALID_PARAMETERS (-2) +#define PSA_FFA_RET_NO_MEMORY (-3) +#define PSA_FFA_RET_BUSY (-4) +#define PSA_FFA_RET_INTERRUPTED (-5) +#define PSA_FFA_RET_DENIED (-6) +#define PSA_FFA_RET_RETRY (-7) +#define PSA_FFA_RET_ABORTED (-8) + +#define MAJOR_VERSION_MASK GENMASK(30, 16) +#define MINOR_VERSION_MASK GENMASK(15, 0) +#define MAJOR_VERSION(x) (u16)(FIELD_GET(MAJOR_VERSION_MASK, (x))) +#define MINOR_VERSION(x) (u16)(FIELD_GET(MINOR_VERSION_MASK, (x))) +#define PACK_VERSION_INFO(major, minor) \ + (FIELD_PREP(MAJOR_VERSION_MASK, (major)) | \ + FIELD_PREP(MINOR_VERSION_MASK, (minor))) +#define PSA_FFA_VERSION_1_0 PACK_VERSION_INFO(1, 0) +#define PSA_FFA_MIN_VERSION PSA_FFA_VERSION_1_0 +#define PSA_FFA_DRIVER_VERSION PSA_FFA_VERSION_1_0 + +#define SENDER_ID_MASK GENMASK(31, 16) +#define RECEIVER_ID_MASK GENMASK(15, 0) +#define SENDER_ID(x) (u16)(FIELD_GET(SENDER_ID_MASK, (x))) +#define RECEIVER_ID(x) (u16)(FIELD_GET(RECEIVER_ID_MASK, (x))) +#define PACK_TARGET_INFO(s, r) \ + (FIELD_PREP(SENDER_ID_MASK, (s)) | FIELD_PREP(RECEIVER_ID_MASK, (r))) + +typedef struct arm_smccc_res +(arm_psa_ffa_fn)(unsigned long, unsigned long, unsigned long, unsigned long, + unsigned long, unsigned long, unsigned long, unsigned long); +static arm_psa_ffa_fn *invoke_arm_psa_ffa_fn; + +static struct device *psa_ffa_dev; + +static const int psa_ffa_linux_errmap[] = { + /* better than switch case as long as return value is continuous */ + 0, /* PSA_FFA_RET_SUCCESS */ + -EOPNOTSUPP, /* PSA_FFA_RET_NOT_SUPPORTED */ + -EINVAL, /* PSA_FFA_RET_INVALID_PARAMETERS */ + -ENOMEM, /* PSA_FFA_RET_NO_MEMORY */ + -EBUSY, /* PSA_FFA_RET_BUSY */ + -EINTR, /* PSA_FFA_RET_INTERRUPTED */ + -EACCES, /* PSA_FFA_RET_DENIED */ + -EAGAIN, /* PSA_FFA_RET_RETRY */ + -ECANCELED, /* PSA_FFA_RET_ABORTED */ +}; + +static inline int psa_ffa_to_linux_errno(int errno) +{ + if (errno < PSA_FFA_RET_SUCCESS && errno >= PSA_FFA_RET_ABORTED) + return psa_ffa_linux_errmap[-errno]; + return -EINVAL; +} + +struct arm_smccc_res +__arm_psa_ffa_fn_smc(unsigned long function_id,unsigned long arg0, + unsigned long arg1, unsigned long arg2, + unsigned long arg3, unsigned long arg4, + unsigned long arg5, unsigned long arg6) +{ + struct arm_smccc_res res; + + arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4, arg5, arg6, + &res); + + return res; +} + +struct arm_smccc_res +__arm_psa_ffa_fn_hvc(unsigned long function_id,unsigned long arg0, + unsigned long arg1, unsigned long arg2, + unsigned long arg3, unsigned long arg4, + unsigned long arg5, unsigned long arg6) +{ + struct arm_smccc_res res; + + arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4, arg5, arg6, + &res); + + return res; +} + +static u16 psa_ffa_id_get(void) +{ + struct arm_smccc_res id; + + id = invoke_arm_psa_ffa_fn(PSA_FFA_ID_GET, 0, 0, 0, 0, 0, 0, 0); + + if (id.a0 == PSA_FFA_ERROR) + return psa_ffa_to_linux_errno((int)id.a2); + else + return id.a2 & 0xffff; +} + +static int psa_ffa_partition_info_get(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3, + struct psa_ffa_partition_info **buffer) +{ + struct arm_smccc_res partition_info; + + partition_info = invoke_arm_psa_ffa_fn(PSA_FFA_PARTITION_INFO_GET, + uuid0, uuid1, uuid2, uuid3, + 0, 0, 0); + + if (partition_info.a0 == PSA_FFA_ERROR) + return psa_ffa_to_linux_errno((int)partition_info.a2); + + /* TODO: read data from RX buffers */ + return partition_info.a2; +} + +static struct arm_psa_ffa_handle drv_handle = { + .id_get = psa_ffa_id_get, + .partition_info_get = psa_ffa_partition_info_get, +}; + +struct arm_psa_ffa_handle *arm_psa_ffa_handle_get(struct device *dev) +{ + struct arm_psa_ffa_handle *handle = NULL; + + if (dev->parent == psa_ffa_dev) + handle = &drv_handle; + + return handle; +} + +EXPORT_SYMBOL_GPL(arm_psa_ffa_handle_get); + +static int psa_ffa_version_check(void) +{ + struct arm_smccc_res version; + + version = invoke_arm_psa_ffa_fn(PSA_FFA_VERSION, PSA_FFA_DRIVER_VERSION, + 0, 0, 0, 0, 0, 0); + + if (version.a0 == PSA_FFA_RET_NOT_SUPPORTED) { + pr_info("PSA_FFA_VERSION returned not supported\n"); + return -ENOTSUPP; + } + + if (version.a0 < PSA_FFA_MIN_VERSION || + version.a0 > PSA_FFA_DRIVER_VERSION) { + pr_err("Incompatible version %d.%d found\n", + MAJOR_VERSION(version.a0), MINOR_VERSION(version.a0)); + return -EINVAL; + } + + pr_info("Found version %d.%d found\n", MAJOR_VERSION(version.a0), + MINOR_VERSION(version.a0)); + return 0; +} + +static int psa_ffa_probe(struct platform_device *pdev) +{ + int ret; + enum arm_smccc_conduit conduit; + + if (arm_smccc_get_version() < ARM_SMCCC_VERSION_1_2) + return 0; + + conduit = arm_smccc_1_1_get_conduit(); + if (conduit == SMCCC_CONDUIT_NONE) { + pr_err("%s: invalid SMCCC conduit\n", __func__); + return -EOPNOTSUPP; + } + + if (conduit == SMCCC_CONDUIT_SMC) + invoke_arm_psa_ffa_fn = __arm_psa_ffa_fn_smc; + else + invoke_arm_psa_ffa_fn = __arm_psa_ffa_fn_hvc; + + ret = psa_ffa_version_check(); + if (ret) + return ret; + + psa_ffa_dev = &pdev->dev; + + return devm_of_platform_populate(psa_ffa_dev); +} + +static const struct of_device_id psa_ffa_of_match[] = { + {.compatible = "arm,psa-ffa"}, + {}, +}; + +MODULE_DEVICE_TABLE(of, psa_ffa_of_match); + +static struct platform_driver psa_ffa_driver = { + .driver = { + .name = "arm-psa-ffa", + .of_match_table = psa_ffa_of_match, + }, + .probe = psa_ffa_probe, +}; + +module_platform_driver(psa_ffa_driver); + +MODULE_ALIAS("platform: arm-psa-ffa"); +MODULE_AUTHOR("Sudeep Holla <sudeep.holla@arm.com>"); +MODULE_DESCRIPTION("Arm PSA FF-A interface driver"); +MODULE_LICENSE("GPL v2"); diff --git a/include/linux/arm_psa_ffa.h b/include/linux/arm_psa_ffa.h new file mode 100644 index 000000000000..03a4ff559fa3 --- /dev/null +++ b/include/linux/arm_psa_ffa.h @@ -0,0 +1,42 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (C) 2019, 2020 Arm Ltd. + */ + +#ifndef __LINUX_ARM_PSA_FFA_H +#define __LINUX_ARM_PSA_FFA_H + +#include <linux/device.h> +#include <linux/types.h> + +struct psa_ffa_partition_info { + /* The ID of the VM the information is about */ + uint16_t id; + /* The number of execution contexts implemented by the partition */ + uint16_t execution_context; + /* The Partition's properties, e.g. supported messaging methods */ + uint32_t partition_properties; +}; + + +/** + * struct psa_ffa_ops - represents the various PSA_FFA protocol operations + * available for an endpoint. + */ +struct arm_psa_ffa_handle { + u16 (*id_get)(void); + int (*partition_info_get)(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3, + struct psa_ffa_partition_info**); +}; + +#if IS_REACHABLE(CONFIG_ARM_PSA_FFA_TRANSPORT) +struct arm_psa_ffa_handle *arm_psa_ffa_handle_get(struct device *dev); +#else +static inline +struct arm_psa_ffa_handle * arm_psa_ffa_handle_get(struct device *dev) +{ + return NULL; +} +#endif + +#endif /*__LINUX_ARM_PSA_FFA_H*/ -- 2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 2/3] firmware: Add support for PSA FF-A transport for VM partitions 2020-06-01 9:45 ` Sudeep Holla (?) @ 2020-06-01 13:46 ` kbuild test robot -1 siblings, 0 replies; 45+ messages in thread From: kbuild test robot @ 2020-06-01 13:46 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 2787 bytes --] Hi Sudeep, [FYI, it's a private test report for your RFC patch.] [auto build test WARNING on next-20200529] [cannot apply to linus/master v5.7 v5.7-rc7 v5.7-rc6 v5.7] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Sudeep-Holla/firmware-Add-support-for-PSA-FF-A-interface/20200601-174706 base: e7b08814b16b80a0bf76eeca16317f8c2ed23b8c config: arm64-allyesconfig (attached as .config) compiler: aarch64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kbuild test robot <lkp@intel.com> All warnings (new ones prefixed by >>, old ones prefixed by <<): >> drivers/firmware/arm_psa_ffa/driver.c:106:1: warning: no previous prototype for '__arm_psa_ffa_fn_smc' [-Wmissing-prototypes] 106 | __arm_psa_ffa_fn_smc(unsigned long function_id,unsigned long arg0, | ^~~~~~~~~~~~~~~~~~~~ >> drivers/firmware/arm_psa_ffa/driver.c:120:1: warning: no previous prototype for '__arm_psa_ffa_fn_hvc' [-Wmissing-prototypes] 120 | __arm_psa_ffa_fn_hvc(unsigned long function_id,unsigned long arg0, | ^~~~~~~~~~~~~~~~~~~~ vim +/__arm_psa_ffa_fn_smc +106 drivers/firmware/arm_psa_ffa/driver.c 104 105 struct arm_smccc_res > 106 __arm_psa_ffa_fn_smc(unsigned long function_id,unsigned long arg0, 107 unsigned long arg1, unsigned long arg2, 108 unsigned long arg3, unsigned long arg4, 109 unsigned long arg5, unsigned long arg6) 110 { 111 struct arm_smccc_res res; 112 113 arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4, arg5, arg6, 114 &res); 115 116 return res; 117 } 118 119 struct arm_smccc_res > 120 __arm_psa_ffa_fn_hvc(unsigned long function_id,unsigned long arg0, 121 unsigned long arg1, unsigned long arg2, 122 unsigned long arg3, unsigned long arg4, 123 unsigned long arg5, unsigned long arg6) 124 { 125 struct arm_smccc_res res; 126 127 arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4, arg5, arg6, 128 &res); 129 130 return res; 131 } 132 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org [-- Attachment #2: config.gz --] [-- Type: application/gzip, Size: 72912 bytes --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 2/3] firmware: Add support for PSA FF-A transport for VM partitions 2020-06-01 9:45 ` Sudeep Holla (?) (?) @ 2020-06-02 7:11 ` kbuild test robot -1 siblings, 0 replies; 45+ messages in thread From: kbuild test robot @ 2020-06-02 7:11 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 3325 bytes --] Hi Sudeep, [FYI, it's a private test report for your RFC patch.] [auto build test WARNING on next-20200529] [cannot apply to linus/master v5.7 v5.7-rc7 v5.7-rc6 v5.7] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Sudeep-Holla/firmware-Add-support-for-PSA-FF-A-interface/20200601-174706 base: e7b08814b16b80a0bf76eeca16317f8c2ed23b8c config: arm64-randconfig-r032-20200602 (attached as .config) compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 2388a096e7865c043e83ece4e26654bd3d1a20d5) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kbuild test robot <lkp@intel.com> All warnings (new ones prefixed by >>, old ones prefixed by <<): >> drivers/firmware/arm_psa_ffa/driver.c:106:1: warning: no previous prototype for function '__arm_psa_ffa_fn_smc' [-Wmissing-prototypes] __arm_psa_ffa_fn_smc(unsigned long function_id,unsigned long arg0, ^ drivers/firmware/arm_psa_ffa/driver.c:105:1: note: declare 'static' if the function is not intended to be used outside of this translation unit struct arm_smccc_res ^ static >> drivers/firmware/arm_psa_ffa/driver.c:120:1: warning: no previous prototype for function '__arm_psa_ffa_fn_hvc' [-Wmissing-prototypes] __arm_psa_ffa_fn_hvc(unsigned long function_id,unsigned long arg0, ^ drivers/firmware/arm_psa_ffa/driver.c:119:1: note: declare 'static' if the function is not intended to be used outside of this translation unit struct arm_smccc_res ^ static 2 warnings generated. vim +/__arm_psa_ffa_fn_smc +106 drivers/firmware/arm_psa_ffa/driver.c 104 105 struct arm_smccc_res > 106 __arm_psa_ffa_fn_smc(unsigned long function_id,unsigned long arg0, 107 unsigned long arg1, unsigned long arg2, 108 unsigned long arg3, unsigned long arg4, 109 unsigned long arg5, unsigned long arg6) 110 { 111 struct arm_smccc_res res; 112 113 arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4, arg5, arg6, 114 &res); 115 116 return res; 117 } 118 119 struct arm_smccc_res > 120 __arm_psa_ffa_fn_hvc(unsigned long function_id,unsigned long arg0, 121 unsigned long arg1, unsigned long arg2, 122 unsigned long arg3, unsigned long arg4, 123 unsigned long arg5, unsigned long arg6) 124 { 125 struct arm_smccc_res res; 126 127 arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4, arg5, arg6, 128 &res); 129 130 return res; 131 } 132 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org [-- Attachment #2: config.gz --] [-- Type: application/gzip, Size: 41106 bytes --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 2/3] firmware: Add support for PSA FF-A transport for VM partitions 2020-06-01 9:45 ` Sudeep Holla @ 2020-07-09 22:15 ` Arve Hjønnevåg -1 siblings, 0 replies; 45+ messages in thread From: Arve Hjønnevåg @ 2020-07-09 22:15 UTC (permalink / raw) To: Sudeep Holla Cc: Will Deacon, devicetree, linux-arm-kernel, LKML, Marc Zyngier On Mon, Jun 1, 2020 at 2:45 AM Sudeep Holla <sudeep.holla@arm.com> wrote: > > Initial support for PSA FF-A interface providing APIs for non-secure VM > partitions. > ... > diff --git a/drivers/firmware/arm_psa_ffa/Kconfig b/drivers/firmware/arm_psa_ffa/Kconfig > new file mode 100644 > index 000000000000..ba699ec68ec4 > --- /dev/null > +++ b/drivers/firmware/arm_psa_ffa/Kconfig > @@ -0,0 +1,15 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +config ARM_PSA_FFA_TRANSPORT > + tristate "Arm Platform Security Architecture Firmware Framework for Armv8-A" > + depends on ARM64 && HAVE_ARM_SMCCC_DISCOVERY Most of this driver should be usable on any platform, so it would be better to only depend on ARM64 in the component that has the arm64 specific implementation of your low level conduit. ... > diff --git a/drivers/firmware/arm_psa_ffa/driver.c b/drivers/firmware/arm_psa_ffa/driver.c > new file mode 100644 > index 000000000000..700bd5850746 > --- /dev/null > +++ b/drivers/firmware/arm_psa_ffa/driver.c ... > + > +typedef struct arm_smccc_res > +(arm_psa_ffa_fn)(unsigned long, unsigned long, unsigned long, unsigned long, > + unsigned long, unsigned long, unsigned long, unsigned long); > +static arm_psa_ffa_fn *invoke_arm_psa_ffa_fn; > + ... > +struct arm_smccc_res > +__arm_psa_ffa_fn_smc(unsigned long function_id,unsigned long arg0, ... > +struct arm_smccc_res > +__arm_psa_ffa_fn_hvc(unsigned long function_id,unsigned long arg0, Can these two functions move out of this file so this driver only depends on a function matching the arm_psa_ffa_fn type? ... > +static int psa_ffa_probe(struct platform_device *pdev) > +{ > + int ret; > + enum arm_smccc_conduit conduit; > + > + if (arm_smccc_get_version() < ARM_SMCCC_VERSION_1_2) > + return 0; > + > + conduit = arm_smccc_1_1_get_conduit(); If you make this device a child device of the conduit, then you don't need this here. Other conduits can be added to for instance support other architectures without adding entries to this enum and modifying this driver. -- Arve Hjønnevåg ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 2/3] firmware: Add support for PSA FF-A transport for VM partitions @ 2020-07-09 22:15 ` Arve Hjønnevåg 0 siblings, 0 replies; 45+ messages in thread From: Arve Hjønnevåg @ 2020-07-09 22:15 UTC (permalink / raw) To: Sudeep Holla Cc: devicetree, Will Deacon, LKML, linux-arm-kernel, Marc Zyngier On Mon, Jun 1, 2020 at 2:45 AM Sudeep Holla <sudeep.holla@arm.com> wrote: > > Initial support for PSA FF-A interface providing APIs for non-secure VM > partitions. > ... > diff --git a/drivers/firmware/arm_psa_ffa/Kconfig b/drivers/firmware/arm_psa_ffa/Kconfig > new file mode 100644 > index 000000000000..ba699ec68ec4 > --- /dev/null > +++ b/drivers/firmware/arm_psa_ffa/Kconfig > @@ -0,0 +1,15 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +config ARM_PSA_FFA_TRANSPORT > + tristate "Arm Platform Security Architecture Firmware Framework for Armv8-A" > + depends on ARM64 && HAVE_ARM_SMCCC_DISCOVERY Most of this driver should be usable on any platform, so it would be better to only depend on ARM64 in the component that has the arm64 specific implementation of your low level conduit. ... > diff --git a/drivers/firmware/arm_psa_ffa/driver.c b/drivers/firmware/arm_psa_ffa/driver.c > new file mode 100644 > index 000000000000..700bd5850746 > --- /dev/null > +++ b/drivers/firmware/arm_psa_ffa/driver.c ... > + > +typedef struct arm_smccc_res > +(arm_psa_ffa_fn)(unsigned long, unsigned long, unsigned long, unsigned long, > + unsigned long, unsigned long, unsigned long, unsigned long); > +static arm_psa_ffa_fn *invoke_arm_psa_ffa_fn; > + ... > +struct arm_smccc_res > +__arm_psa_ffa_fn_smc(unsigned long function_id,unsigned long arg0, ... > +struct arm_smccc_res > +__arm_psa_ffa_fn_hvc(unsigned long function_id,unsigned long arg0, Can these two functions move out of this file so this driver only depends on a function matching the arm_psa_ffa_fn type? ... > +static int psa_ffa_probe(struct platform_device *pdev) > +{ > + int ret; > + enum arm_smccc_conduit conduit; > + > + if (arm_smccc_get_version() < ARM_SMCCC_VERSION_1_2) > + return 0; > + > + conduit = arm_smccc_1_1_get_conduit(); If you make this device a child device of the conduit, then you don't need this here. Other conduits can be added to for instance support other architectures without adding entries to this enum and modifying this driver. -- Arve Hjønnevåg _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 45+ messages in thread
* [RFC PATCH 3/3] firmware: Add example PSA FF-A non-secure VM partition 2020-06-01 9:45 ` Sudeep Holla @ 2020-06-01 9:45 ` Sudeep Holla -1 siblings, 0 replies; 45+ messages in thread From: Sudeep Holla @ 2020-06-01 9:45 UTC (permalink / raw) To: Will Deacon, devicetree, linux-arm-kernel Cc: Sudeep Holla, linux-kernel, Marc Zyngier This is just an example non-secure VM partition to show how to create the device and use the PSA FF-A interface APIs. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> --- drivers/firmware/arm_psa_ffa/Kconfig | 7 +++ drivers/firmware/arm_psa_ffa/Makefile | 1 + drivers/firmware/arm_psa_ffa/partition.c | 71 ++++++++++++++++++++++++ 3 files changed, 79 insertions(+) create mode 100644 drivers/firmware/arm_psa_ffa/partition.c diff --git a/drivers/firmware/arm_psa_ffa/Kconfig b/drivers/firmware/arm_psa_ffa/Kconfig index ba699ec68ec4..34ad61e79234 100644 --- a/drivers/firmware/arm_psa_ffa/Kconfig +++ b/drivers/firmware/arm_psa_ffa/Kconfig @@ -13,3 +13,10 @@ config ARM_PSA_FFA_TRANSPORT This driver provides interface for all the client drivers making use of the features offered by ARM PSA-FF-A. + +config ARM_PSA_FFA_PARTITION + tristate "Arm PSA FF-A compliant partition" + depends on ARM_PSA_FFA_TRANSPORT + help + This driver provides example for ARM PSA-FF-A client driver + making use of the interfaces offered by ARM PSA-FF-A driver. diff --git a/drivers/firmware/arm_psa_ffa/Makefile b/drivers/firmware/arm_psa_ffa/Makefile index ac0455ff71a4..8eb03898baf7 100644 --- a/drivers/firmware/arm_psa_ffa/Makefile +++ b/drivers/firmware/arm_psa_ffa/Makefile @@ -1,2 +1,3 @@ # SPDX-License-Identifier: GPL-2.0-only obj-$(CONFIG_ARM_PSA_FFA_TRANSPORT) += driver.o +obj-$(CONFIG_ARM_PSA_FFA_PARTITION) += partition.o diff --git a/drivers/firmware/arm_psa_ffa/partition.c b/drivers/firmware/arm_psa_ffa/partition.c new file mode 100644 index 000000000000..8549f8d61454 --- /dev/null +++ b/drivers/firmware/arm_psa_ffa/partition.c @@ -0,0 +1,71 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Arm PSA FFA example partition driver + * + * Copyright (C) 2020 Arm Ltd. + */ + +#include <linux/arm_psa_ffa.h> +#include <linux/of_address.h> +#include <linux/of_platform.h> +#include <linux/platform_device.h> +#include <linux/module.h> +#include <linux/types.h> +#include <linux/uuid.h> + +static int psa_ffa_partition_probe(struct platform_device *pdev) +{ + u16 vm_id; + uuid_t uuid; + const char *uuid_str; + u32 uuid0_4[4]; + struct device *dev = &pdev->dev; + const struct device_node *np = dev->of_node; + struct arm_psa_ffa_handle *handle; + struct psa_ffa_partition_info **buffer; + + handle = arm_psa_ffa_handle_get(dev); + if (!handle) + return -ENODEV; + + if (of_property_read_string(np, "uuid", &uuid_str)) { + dev_err(dev, "failed to parse \"uuid\" property in '%pOF'\n", np); + return -ENODEV; + } + + if (uuid_parse(uuid_str, &uuid)) { + dev_err(dev, "invalid \"uuid\" property (%s)\n", uuid_str); + return -ENODEV; + } + + export_uuid((u8 *)uuid0_4, &uuid); + + vm_id = handle->id_get(); + + handle->partition_info_get(uuid0_4[0], uuid0_4[1], uuid0_4[2], + uuid0_4[3], buffer); + + return 0; +} + +static const struct of_device_id psa_ffa_partition_of_match[] = { + {.compatible = "arm,psa-ffa-partition"}, + {}, +}; + +MODULE_DEVICE_TABLE(of, psa_ffa_partition_of_match); + +static struct platform_driver psa_ffa_partition_driver = { + .driver = { + .name = "psa-ffa-partition", + .of_match_table = psa_ffa_partition_of_match, + }, + .probe = psa_ffa_partition_probe, +}; + +module_platform_driver(psa_ffa_partition_driver); + +MODULE_ALIAS("platform: arm-psa-ffa"); +MODULE_AUTHOR("Sudeep Holla <sudeep.holla@arm.com>"); +MODULE_DESCRIPTION("Arm PSA FF-A example partition driver"); +MODULE_LICENSE("GPL v2"); -- 2.17.1 ^ permalink raw reply related [flat|nested] 45+ messages in thread
* [RFC PATCH 3/3] firmware: Add example PSA FF-A non-secure VM partition @ 2020-06-01 9:45 ` Sudeep Holla 0 siblings, 0 replies; 45+ messages in thread From: Sudeep Holla @ 2020-06-01 9:45 UTC (permalink / raw) To: Will Deacon, devicetree, linux-arm-kernel Cc: Marc Zyngier, linux-kernel, Sudeep Holla This is just an example non-secure VM partition to show how to create the device and use the PSA FF-A interface APIs. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> --- drivers/firmware/arm_psa_ffa/Kconfig | 7 +++ drivers/firmware/arm_psa_ffa/Makefile | 1 + drivers/firmware/arm_psa_ffa/partition.c | 71 ++++++++++++++++++++++++ 3 files changed, 79 insertions(+) create mode 100644 drivers/firmware/arm_psa_ffa/partition.c diff --git a/drivers/firmware/arm_psa_ffa/Kconfig b/drivers/firmware/arm_psa_ffa/Kconfig index ba699ec68ec4..34ad61e79234 100644 --- a/drivers/firmware/arm_psa_ffa/Kconfig +++ b/drivers/firmware/arm_psa_ffa/Kconfig @@ -13,3 +13,10 @@ config ARM_PSA_FFA_TRANSPORT This driver provides interface for all the client drivers making use of the features offered by ARM PSA-FF-A. + +config ARM_PSA_FFA_PARTITION + tristate "Arm PSA FF-A compliant partition" + depends on ARM_PSA_FFA_TRANSPORT + help + This driver provides example for ARM PSA-FF-A client driver + making use of the interfaces offered by ARM PSA-FF-A driver. diff --git a/drivers/firmware/arm_psa_ffa/Makefile b/drivers/firmware/arm_psa_ffa/Makefile index ac0455ff71a4..8eb03898baf7 100644 --- a/drivers/firmware/arm_psa_ffa/Makefile +++ b/drivers/firmware/arm_psa_ffa/Makefile @@ -1,2 +1,3 @@ # SPDX-License-Identifier: GPL-2.0-only obj-$(CONFIG_ARM_PSA_FFA_TRANSPORT) += driver.o +obj-$(CONFIG_ARM_PSA_FFA_PARTITION) += partition.o diff --git a/drivers/firmware/arm_psa_ffa/partition.c b/drivers/firmware/arm_psa_ffa/partition.c new file mode 100644 index 000000000000..8549f8d61454 --- /dev/null +++ b/drivers/firmware/arm_psa_ffa/partition.c @@ -0,0 +1,71 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Arm PSA FFA example partition driver + * + * Copyright (C) 2020 Arm Ltd. + */ + +#include <linux/arm_psa_ffa.h> +#include <linux/of_address.h> +#include <linux/of_platform.h> +#include <linux/platform_device.h> +#include <linux/module.h> +#include <linux/types.h> +#include <linux/uuid.h> + +static int psa_ffa_partition_probe(struct platform_device *pdev) +{ + u16 vm_id; + uuid_t uuid; + const char *uuid_str; + u32 uuid0_4[4]; + struct device *dev = &pdev->dev; + const struct device_node *np = dev->of_node; + struct arm_psa_ffa_handle *handle; + struct psa_ffa_partition_info **buffer; + + handle = arm_psa_ffa_handle_get(dev); + if (!handle) + return -ENODEV; + + if (of_property_read_string(np, "uuid", &uuid_str)) { + dev_err(dev, "failed to parse \"uuid\" property in '%pOF'\n", np); + return -ENODEV; + } + + if (uuid_parse(uuid_str, &uuid)) { + dev_err(dev, "invalid \"uuid\" property (%s)\n", uuid_str); + return -ENODEV; + } + + export_uuid((u8 *)uuid0_4, &uuid); + + vm_id = handle->id_get(); + + handle->partition_info_get(uuid0_4[0], uuid0_4[1], uuid0_4[2], + uuid0_4[3], buffer); + + return 0; +} + +static const struct of_device_id psa_ffa_partition_of_match[] = { + {.compatible = "arm,psa-ffa-partition"}, + {}, +}; + +MODULE_DEVICE_TABLE(of, psa_ffa_partition_of_match); + +static struct platform_driver psa_ffa_partition_driver = { + .driver = { + .name = "psa-ffa-partition", + .of_match_table = psa_ffa_partition_of_match, + }, + .probe = psa_ffa_partition_probe, +}; + +module_platform_driver(psa_ffa_partition_driver); + +MODULE_ALIAS("platform: arm-psa-ffa"); +MODULE_AUTHOR("Sudeep Holla <sudeep.holla@arm.com>"); +MODULE_DESCRIPTION("Arm PSA FF-A example partition driver"); +MODULE_LICENSE("GPL v2"); -- 2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 3/3] firmware: Add example PSA FF-A non-secure VM partition 2020-06-01 9:45 ` Sudeep Holla (?) @ 2020-06-01 14:22 ` kbuild test robot -1 siblings, 0 replies; 45+ messages in thread From: kbuild test robot @ 2020-06-01 14:22 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 2689 bytes --] Hi Sudeep, [FYI, it's a private test report for your RFC patch.] [auto build test WARNING on next-20200529] [cannot apply to linus/master v5.7 v5.7-rc7 v5.7-rc6 v5.7] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Sudeep-Holla/firmware-Add-support-for-PSA-FF-A-interface/20200601-174706 base: e7b08814b16b80a0bf76eeca16317f8c2ed23b8c config: arm64-allyesconfig (attached as .config) compiler: aarch64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kbuild test robot <lkp@intel.com> All warnings (new ones prefixed by >>, old ones prefixed by <<): drivers/firmware/arm_psa_ffa/partition.c: In function 'psa_ffa_partition_probe': >> drivers/firmware/arm_psa_ffa/partition.c:18:6: warning: variable 'vm_id' set but not used [-Wunused-but-set-variable] 18 | u16 vm_id; | ^~~~~ vim +/vm_id +18 drivers/firmware/arm_psa_ffa/partition.c 15 16 static int psa_ffa_partition_probe(struct platform_device *pdev) 17 { > 18 u16 vm_id; 19 uuid_t uuid; 20 const char *uuid_str; 21 u32 uuid0_4[4]; 22 struct device *dev = &pdev->dev; 23 const struct device_node *np = dev->of_node; 24 struct arm_psa_ffa_handle *handle; 25 struct psa_ffa_partition_info **buffer; 26 27 handle = arm_psa_ffa_handle_get(dev); 28 if (!handle) 29 return -ENODEV; 30 31 if (of_property_read_string(np, "uuid", &uuid_str)) { 32 dev_err(dev, "failed to parse \"uuid\" property in '%pOF'\n", np); 33 return -ENODEV; 34 } 35 36 if (uuid_parse(uuid_str, &uuid)) { 37 dev_err(dev, "invalid \"uuid\" property (%s)\n", uuid_str); 38 return -ENODEV; 39 } 40 41 export_uuid((u8 *)uuid0_4, &uuid); 42 43 vm_id = handle->id_get(); 44 45 handle->partition_info_get(uuid0_4[0], uuid0_4[1], uuid0_4[2], 46 uuid0_4[3], buffer); 47 48 return 0; 49 } 50 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org [-- Attachment #2: config.gz --] [-- Type: application/gzip, Size: 72917 bytes --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface 2020-06-01 9:45 ` Sudeep Holla @ 2020-06-04 13:37 ` Will Deacon -1 siblings, 0 replies; 45+ messages in thread From: Will Deacon @ 2020-06-04 13:37 UTC (permalink / raw) To: Sudeep Holla Cc: devicetree, linux-arm-kernel, linux-kernel, Marc Zyngier, tabba, qwandor, ardb Hi Sudeep, [+Fuad, Andrew and Ard] (To other interested readers: if you haven't seen it, the FF-A spec is here: https://static.docs.arm.com/den0077/a/DEN0077A_PSA_Firmware_Framework_Arm_v8-A_1.0_EAC.pdf since this discussion makes no sense without that, and a tiny bit of sense with it. It used to be called "SPCI" but it was recently renamed.) On Mon, Jun 01, 2020 at 10:45:09AM +0100, Sudeep Holla wrote: > Sorry for posting in the middle of merge window and I must have done > this last week itself. This is not the driver I had thought about posting > last week. After I started cleaning up and looking at Will's KVM prototype[1] > for PSA FF-A (previously known as SPCI), Yes, I need to do the Big Rename at some point. Joy. > I got more doubts on alignment and dropped huge chunk of interface APIs in > the driver in order to keep it simple, and get aligned more with that > prototype and avoid scanning lots of code unnecessary. You also dropped most of the code, so this doesn't really do anything in its current form ;) > Here are few things to clarify: > > 1. DT bindings > --------------- > I was initially against adding bindings for Tx/Rx buffers for > partitions. As per the spec, an endpoint could allocate the > buffer pair and use the FFA_RXTX_MAP interface to map it with the > Hypervisor(KVM here). However looking at the prototype and also > I remember you mentioning that it is not possible to manage buffers > in that way. Please confirm if you plan to add the buffer details > fetcthing them through ioctls in KVM and adding them to VM DT nodes > in KVM userspace. I will update the bindings accordingly. I think it's useful to have a mode of operation where the hypervisor allocates the RX/TX buffers and advertises them in the DT. However, we can always add this later, so there's no need to have it in the binding from the start. Best start as simple as possible, I reckon. Setting the static RX/TX buffer allocation aside, why is a DT node needed at all for the case where Linux is running purely as an FF-A client? I thought everything should be discoverable via FFA_VERSION, FFA_FEATURES, FFA_PARTITION_INFO_GET and FFA_ID_GET? That should mean we can get away without a binding at all for the client case. > 2. Driver > --------- > a. Support for multiple partitions in a VM > ------------------------------------------ > I am not sure if there is need for supporting multiple partitions > within a VM. It should be possible to do so as I expect to create > device for each partition entry under arm-psa-ffa devicetree node. > However, I don't want to assume something that will never be a > usecase. However I don't think this will change must of the > abstraction as we need to keep the interface API implementation > separate to support different partitions on various platforms. I think Ard has a case for something like this, where a VM actually consists of multiple partitions so that S-EL0 services can be provided from NS-EL0. However, he probably wants that for a dynamically created VM, so we'd need a way to instantiate an FFA namespace for the VM. Maybe that can be done entirely in userspace by the VMM... > b. SMCCC interface > ------------------ > This is something I messed up completely while trying to add > support for SMCCC v1.2. It now supports x0-x17 as parameter > registers(input) and return registers(output). I started simple > with x0-x7 as both input and output as PSA FF-A needs that at > most. But extending to x0-x17 then became with messy in my > implementation. That's the reason I dropped it completely > here and thought of checking it first. > > Do we need to extend the optimisations that were done to handle > ARCH_WORKAROUND_{1,2}. Or should be just use a version with x0-x7 > as both input and ouput. Hyper-V guys need full x0-x17 support. > > I need some guidance as what is the approach preferred ? I think we can start off with x0-x7 and extend if later if we need to. > 3. Partitions > ------------- > I am not sure if we have a full define partition that we plan to > push upstream. Without one, we can have a sample/example partition > to test all the interface APIs, but is that fine with respect to > what we want upstream ? Any other thoughts that helps to test the > driver ? I think that's the best you can do for now. We can probably help with testing as our stuff gets off the ground. > Sorry for long email and too many questions, but I thought it is easier > this way to begin with than throwing huge code implementing loads of APIs > with no users(expect example partition) especially that I am posting this > during merge window. No problem. Maybe it would help if I described roughly what we were thinking of doing for KVM (this is open for discussion, of course): 1. Describe KVM-managed partitions in the DT, along the lines of [1] 2. Expose each partition as a file to userspace. E.g.: /dev/spci/: self e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8 49f65057-d002-4ae2-b4ee-d31c7940a13d Here, self would be a symlink to the host uuid. The host uuid file would implement FFA_MEM operations using an ioctl(), so you could, for example, share a user buffer with multiple partitions by issuing a MEM_SHARE ioctl() on self, passing the fds for the borrower partitions as arguments. Messaging would be implemented as ioctl()s on the partition uuid files themselves. 3. We'll need some (all?) of these patches to unmap memory from the host when necessary: https://lwn.net/Articles/821215/ (for nVHE, we'll have a stage-2 for the host so we can unmap there as well) For communicating with partitions that are not managed by KVM (e.g. trusted applications), it's not clear to me how much of that will be handled in kernel or user. I think it would still be worth exposing the partitions as files, but perhaps having them root only or just returning -EPERM for the ioctl() if a kernel driver has claimed the partition as its own? Ideally, FF-A would allow us to transition some of the Trusted OS interfacing code out to userspace, but I don't know how realistic that is. Anyway, to enable this, I think we need a clear separation in the kernel between the FF-A code and the users: KVM will want to expose things as above, but if drivers need to use this stuff as well then they can plug in as additional users and we don't have to worry about tripping over the RX/TX buffers etc. What do you think, and do you reckon you can spin a cut-down driver that implements the common part of the logic (since I know you've written much of this code already)? Cheers, Will [1] https://android-kvm.googlesource.com/linux/+/8632a5723ef106017c4ab57e95d9ce7630d35522%5E%21/#F0 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface @ 2020-06-04 13:37 ` Will Deacon 0 siblings, 0 replies; 45+ messages in thread From: Will Deacon @ 2020-06-04 13:37 UTC (permalink / raw) To: Sudeep Holla Cc: devicetree, qwandor, Marc Zyngier, linux-kernel, linux-arm-kernel, ardb, tabba Hi Sudeep, [+Fuad, Andrew and Ard] (To other interested readers: if you haven't seen it, the FF-A spec is here: https://static.docs.arm.com/den0077/a/DEN0077A_PSA_Firmware_Framework_Arm_v8-A_1.0_EAC.pdf since this discussion makes no sense without that, and a tiny bit of sense with it. It used to be called "SPCI" but it was recently renamed.) On Mon, Jun 01, 2020 at 10:45:09AM +0100, Sudeep Holla wrote: > Sorry for posting in the middle of merge window and I must have done > this last week itself. This is not the driver I had thought about posting > last week. After I started cleaning up and looking at Will's KVM prototype[1] > for PSA FF-A (previously known as SPCI), Yes, I need to do the Big Rename at some point. Joy. > I got more doubts on alignment and dropped huge chunk of interface APIs in > the driver in order to keep it simple, and get aligned more with that > prototype and avoid scanning lots of code unnecessary. You also dropped most of the code, so this doesn't really do anything in its current form ;) > Here are few things to clarify: > > 1. DT bindings > --------------- > I was initially against adding bindings for Tx/Rx buffers for > partitions. As per the spec, an endpoint could allocate the > buffer pair and use the FFA_RXTX_MAP interface to map it with the > Hypervisor(KVM here). However looking at the prototype and also > I remember you mentioning that it is not possible to manage buffers > in that way. Please confirm if you plan to add the buffer details > fetcthing them through ioctls in KVM and adding them to VM DT nodes > in KVM userspace. I will update the bindings accordingly. I think it's useful to have a mode of operation where the hypervisor allocates the RX/TX buffers and advertises them in the DT. However, we can always add this later, so there's no need to have it in the binding from the start. Best start as simple as possible, I reckon. Setting the static RX/TX buffer allocation aside, why is a DT node needed at all for the case where Linux is running purely as an FF-A client? I thought everything should be discoverable via FFA_VERSION, FFA_FEATURES, FFA_PARTITION_INFO_GET and FFA_ID_GET? That should mean we can get away without a binding at all for the client case. > 2. Driver > --------- > a. Support for multiple partitions in a VM > ------------------------------------------ > I am not sure if there is need for supporting multiple partitions > within a VM. It should be possible to do so as I expect to create > device for each partition entry under arm-psa-ffa devicetree node. > However, I don't want to assume something that will never be a > usecase. However I don't think this will change must of the > abstraction as we need to keep the interface API implementation > separate to support different partitions on various platforms. I think Ard has a case for something like this, where a VM actually consists of multiple partitions so that S-EL0 services can be provided from NS-EL0. However, he probably wants that for a dynamically created VM, so we'd need a way to instantiate an FFA namespace for the VM. Maybe that can be done entirely in userspace by the VMM... > b. SMCCC interface > ------------------ > This is something I messed up completely while trying to add > support for SMCCC v1.2. It now supports x0-x17 as parameter > registers(input) and return registers(output). I started simple > with x0-x7 as both input and output as PSA FF-A needs that at > most. But extending to x0-x17 then became with messy in my > implementation. That's the reason I dropped it completely > here and thought of checking it first. > > Do we need to extend the optimisations that were done to handle > ARCH_WORKAROUND_{1,2}. Or should be just use a version with x0-x7 > as both input and ouput. Hyper-V guys need full x0-x17 support. > > I need some guidance as what is the approach preferred ? I think we can start off with x0-x7 and extend if later if we need to. > 3. Partitions > ------------- > I am not sure if we have a full define partition that we plan to > push upstream. Without one, we can have a sample/example partition > to test all the interface APIs, but is that fine with respect to > what we want upstream ? Any other thoughts that helps to test the > driver ? I think that's the best you can do for now. We can probably help with testing as our stuff gets off the ground. > Sorry for long email and too many questions, but I thought it is easier > this way to begin with than throwing huge code implementing loads of APIs > with no users(expect example partition) especially that I am posting this > during merge window. No problem. Maybe it would help if I described roughly what we were thinking of doing for KVM (this is open for discussion, of course): 1. Describe KVM-managed partitions in the DT, along the lines of [1] 2. Expose each partition as a file to userspace. E.g.: /dev/spci/: self e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8 49f65057-d002-4ae2-b4ee-d31c7940a13d Here, self would be a symlink to the host uuid. The host uuid file would implement FFA_MEM operations using an ioctl(), so you could, for example, share a user buffer with multiple partitions by issuing a MEM_SHARE ioctl() on self, passing the fds for the borrower partitions as arguments. Messaging would be implemented as ioctl()s on the partition uuid files themselves. 3. We'll need some (all?) of these patches to unmap memory from the host when necessary: https://lwn.net/Articles/821215/ (for nVHE, we'll have a stage-2 for the host so we can unmap there as well) For communicating with partitions that are not managed by KVM (e.g. trusted applications), it's not clear to me how much of that will be handled in kernel or user. I think it would still be worth exposing the partitions as files, but perhaps having them root only or just returning -EPERM for the ioctl() if a kernel driver has claimed the partition as its own? Ideally, FF-A would allow us to transition some of the Trusted OS interfacing code out to userspace, but I don't know how realistic that is. Anyway, to enable this, I think we need a clear separation in the kernel between the FF-A code and the users: KVM will want to expose things as above, but if drivers need to use this stuff as well then they can plug in as additional users and we don't have to worry about tripping over the RX/TX buffers etc. What do you think, and do you reckon you can spin a cut-down driver that implements the common part of the logic (since I know you've written much of this code already)? Cheers, Will [1] https://android-kvm.googlesource.com/linux/+/8632a5723ef106017c4ab57e95d9ce7630d35522%5E%21/#F0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface 2020-06-04 13:37 ` Will Deacon @ 2020-06-09 17:41 ` Sudeep Holla -1 siblings, 0 replies; 45+ messages in thread From: Sudeep Holla @ 2020-06-09 17:41 UTC (permalink / raw) To: Will Deacon Cc: devicetree, linux-arm-kernel, linux-kernel, Marc Zyngier, tabba, qwandor, ardb, Sudeep Holla (Sorry for the delay, got distracted with some other bug fix.) On Thu, Jun 04, 2020 at 02:37:46PM +0100, Will Deacon wrote: > Hi Sudeep, [+Fuad, Andrew and Ard] > > (To other interested readers: if you haven't seen it, the FF-A spec is here: > https://static.docs.arm.com/den0077/a/DEN0077A_PSA_Firmware_Framework_Arm_v8-A_1.0_EAC.pdf > since this discussion makes no sense without that, and a tiny bit of sense > with it. It used to be called "SPCI" but it was recently renamed.) > Thanks for adding all interested parties. > On Mon, Jun 01, 2020 at 10:45:09AM +0100, Sudeep Holla wrote: > > Sorry for posting in the middle of merge window and I must have done > > this last week itself. This is not the driver I had thought about posting > > last week. After I started cleaning up and looking at Will's KVM prototype[1] > > for PSA FF-A (previously known as SPCI), > > Yes, I need to do the Big Rename at some point. Joy. > 😁 > > I got more doubts on alignment and dropped huge chunk of interface APIs in > > the driver in order to keep it simple, and get aligned more with that > > prototype and avoid scanning lots of code unnecessary. > > You also dropped most of the code, so this doesn't really do anything in > its current form ;) > Yes, it was intentional 😉 > > Here are few things to clarify: > > > > 1. DT bindings > > --------------- > > I was initially against adding bindings for Tx/Rx buffers for > > partitions. As per the spec, an endpoint could allocate the > > buffer pair and use the FFA_RXTX_MAP interface to map it with the > > Hypervisor(KVM here). However looking at the prototype and also > > I remember you mentioning that it is not possible to manage buffers > > in that way. Please confirm if you plan to add the buffer details > > fetcthing them through ioctls in KVM and adding them to VM DT nodes > > in KVM userspace. I will update the bindings accordingly. > > I think it's useful to have a mode of operation where the hypervisor > allocates the RX/TX buffers and advertises them in the DT. However, we > can always add this later, so there's no need to have it in the binding > from the start. Best start as simple as possible, I reckon. > OK > Setting the static RX/TX buffer allocation aside, why is a DT node needed > at all for the case where Linux is running purely as an FF-A client? I > thought everything should be discoverable via FFA_VERSION, FFA_FEATURES, > FFA_PARTITION_INFO_GET and FFA_ID_GET? That should mean we can get away > without a binding at all for the client case. > Agreed, I added for RxTx buffers and initially to build the parent/child hierarchy for all users of the driver. Initially I was assuming only in-kernel users and now I agree we should avoid any in kernel users if possible. One thing to note FFA_PARTITION_INFO_GET relies on Rx buffers to send the information to the caller. So we need to have established buffers before that and one of the reason you don't find that in this RFC. I dropped that too which I wanted initially. > > 2. Driver > > --------- > > a. Support for multiple partitions in a VM > > ------------------------------------------ > > I am not sure if there is need for supporting multiple partitions > > within a VM. It should be possible to do so as I expect to create > > device for each partition entry under arm-psa-ffa devicetree node. > > However, I don't want to assume something that will never be a > > usecase. However I don't think this will change must of the > > abstraction as we need to keep the interface API implementation > > separate to support different partitions on various platforms. > > I think Ard has a case for something like this, where a VM actually consists > of multiple partitions so that S-EL0 services can be provided from NS-EL0. > However, he probably wants that for a dynamically created VM, so we'd > need a way to instantiate an FFA namespace for the VM. Maybe that can be > done entirely in userspace by the VMM... > Interesting... > > b. SMCCC interface > > ------------------ > > This is something I messed up completely while trying to add > > support for SMCCC v1.2. It now supports x0-x17 as parameter > > registers(input) and return registers(output). I started simple > > with x0-x7 as both input and output as PSA FF-A needs that at > > most. But extending to x0-x17 then became with messy in my > > implementation. That's the reason I dropped it completely > > here and thought of checking it first. > > > > Do we need to extend the optimisations that were done to handle > > ARCH_WORKAROUND_{1,2}. Or should be just use a version with x0-x7 > > as both input and ouput. Hyper-V guys need full x0-x17 support. > > > > I need some guidance as what is the approach preferred ? > > I think we can start off with x0-x7 and extend if later if we need to. > Sure > > 3. Partitions > > ------------- > > I am not sure if we have a full define partition that we plan to > > push upstream. Without one, we can have a sample/example partition > > to test all the interface APIs, but is that fine with respect to > > what we want upstream ? Any other thoughts that helps to test the > > driver ? > > I think that's the best you can do for now. We can probably help with > testing as our stuff gets off the ground. > OK > > Sorry for long email and too many questions, but I thought it is easier > > this way to begin with than throwing huge code implementing loads of APIs > > with no users(expect example partition) especially that I am posting this > > during merge window. > > No problem. Maybe it would help if I described roughly what we were thinking > of doing for KVM (this is open for discussion, of course): > > 1. Describe KVM-managed partitions in the DT, along the lines of [1] > 2. Expose each partition as a file to userspace. E.g.: > > /dev/spci/: > > self > e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8 > 49f65057-d002-4ae2-b4ee-d31c7940a13d > > Here, self would be a symlink to the host uuid. The host uuid file > would implement FFA_MEM operations using an ioctl(), so you could, > for example, share a user buffer with multiple partitions by issuing > a MEM_SHARE ioctl() on self, passing the fds for the borrower partitions > as arguments. Messaging would be implemented as ioctl()s on the > partition uuid files themselves. > OK, IIUC that covers mostly KVM implementation. We still need a way to share the RxTx buffer info to the partitions and DT/ACPI(?) is one possible way. Based on you comment about not needing DT node, do you have any other way to communicate the buffer info to the partitions ? > 3. We'll need some (all?) of these patches to unmap memory from the host > when necessary: > > https://lwn.net/Articles/821215/ > > (for nVHE, we'll have a stage-2 for the host so we can unmap there as > well) > Sounds more fun. > For communicating with partitions that are not managed by KVM (e.g. trusted > applications), it's not clear to me how much of that will be handled in > kernel or user. I think it would still be worth exposing the partitions as > files, but perhaps having them root only or just returning -EPERM for the > ioctl() if a kernel driver has claimed the partition as its own? Ideally, > FF-A would allow us to transition some of the Trusted OS interfacing code > out to userspace, but I don't know how realistic that is. > Ah good, so we can still manage in-kernel users this way but we need to provide interface to such a driver which I agree that we need to avoid if possible. > Anyway, to enable this, I think we need a clear separation in the kernel > between the FF-A code and the users: Agreed. > KVM will want to expose things as above, but if drivers need to use this > stuff as well then they can plug in as additional users and we don't have to > worry about tripping over the RX/TX buffers etc. > I am confused a bit. When you refer drivers above, are you referring to drivers in host kernel(hypervisor) or in the partitions. I fail to imagine need for the former. > What do you think, and do you reckon you can spin a cut-down driver that > implements the common part of the logic (since I know you've written much > of this code already)? > I am not sure if I am aligned with your thoughts on the buffer sharing yet. -- Regards, Sudeep ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface @ 2020-06-09 17:41 ` Sudeep Holla 0 siblings, 0 replies; 45+ messages in thread From: Sudeep Holla @ 2020-06-09 17:41 UTC (permalink / raw) To: Will Deacon Cc: devicetree, qwandor, Marc Zyngier, linux-kernel, linux-arm-kernel, Sudeep Holla, ardb, tabba (Sorry for the delay, got distracted with some other bug fix.) On Thu, Jun 04, 2020 at 02:37:46PM +0100, Will Deacon wrote: > Hi Sudeep, [+Fuad, Andrew and Ard] > > (To other interested readers: if you haven't seen it, the FF-A spec is here: > https://static.docs.arm.com/den0077/a/DEN0077A_PSA_Firmware_Framework_Arm_v8-A_1.0_EAC.pdf > since this discussion makes no sense without that, and a tiny bit of sense > with it. It used to be called "SPCI" but it was recently renamed.) > Thanks for adding all interested parties. > On Mon, Jun 01, 2020 at 10:45:09AM +0100, Sudeep Holla wrote: > > Sorry for posting in the middle of merge window and I must have done > > this last week itself. This is not the driver I had thought about posting > > last week. After I started cleaning up and looking at Will's KVM prototype[1] > > for PSA FF-A (previously known as SPCI), > > Yes, I need to do the Big Rename at some point. Joy. > 😁 > > I got more doubts on alignment and dropped huge chunk of interface APIs in > > the driver in order to keep it simple, and get aligned more with that > > prototype and avoid scanning lots of code unnecessary. > > You also dropped most of the code, so this doesn't really do anything in > its current form ;) > Yes, it was intentional 😉 > > Here are few things to clarify: > > > > 1. DT bindings > > --------------- > > I was initially against adding bindings for Tx/Rx buffers for > > partitions. As per the spec, an endpoint could allocate the > > buffer pair and use the FFA_RXTX_MAP interface to map it with the > > Hypervisor(KVM here). However looking at the prototype and also > > I remember you mentioning that it is not possible to manage buffers > > in that way. Please confirm if you plan to add the buffer details > > fetcthing them through ioctls in KVM and adding them to VM DT nodes > > in KVM userspace. I will update the bindings accordingly. > > I think it's useful to have a mode of operation where the hypervisor > allocates the RX/TX buffers and advertises them in the DT. However, we > can always add this later, so there's no need to have it in the binding > from the start. Best start as simple as possible, I reckon. > OK > Setting the static RX/TX buffer allocation aside, why is a DT node needed > at all for the case where Linux is running purely as an FF-A client? I > thought everything should be discoverable via FFA_VERSION, FFA_FEATURES, > FFA_PARTITION_INFO_GET and FFA_ID_GET? That should mean we can get away > without a binding at all for the client case. > Agreed, I added for RxTx buffers and initially to build the parent/child hierarchy for all users of the driver. Initially I was assuming only in-kernel users and now I agree we should avoid any in kernel users if possible. One thing to note FFA_PARTITION_INFO_GET relies on Rx buffers to send the information to the caller. So we need to have established buffers before that and one of the reason you don't find that in this RFC. I dropped that too which I wanted initially. > > 2. Driver > > --------- > > a. Support for multiple partitions in a VM > > ------------------------------------------ > > I am not sure if there is need for supporting multiple partitions > > within a VM. It should be possible to do so as I expect to create > > device for each partition entry under arm-psa-ffa devicetree node. > > However, I don't want to assume something that will never be a > > usecase. However I don't think this will change must of the > > abstraction as we need to keep the interface API implementation > > separate to support different partitions on various platforms. > > I think Ard has a case for something like this, where a VM actually consists > of multiple partitions so that S-EL0 services can be provided from NS-EL0. > However, he probably wants that for a dynamically created VM, so we'd > need a way to instantiate an FFA namespace for the VM. Maybe that can be > done entirely in userspace by the VMM... > Interesting... > > b. SMCCC interface > > ------------------ > > This is something I messed up completely while trying to add > > support for SMCCC v1.2. It now supports x0-x17 as parameter > > registers(input) and return registers(output). I started simple > > with x0-x7 as both input and output as PSA FF-A needs that at > > most. But extending to x0-x17 then became with messy in my > > implementation. That's the reason I dropped it completely > > here and thought of checking it first. > > > > Do we need to extend the optimisations that were done to handle > > ARCH_WORKAROUND_{1,2}. Or should be just use a version with x0-x7 > > as both input and ouput. Hyper-V guys need full x0-x17 support. > > > > I need some guidance as what is the approach preferred ? > > I think we can start off with x0-x7 and extend if later if we need to. > Sure > > 3. Partitions > > ------------- > > I am not sure if we have a full define partition that we plan to > > push upstream. Without one, we can have a sample/example partition > > to test all the interface APIs, but is that fine with respect to > > what we want upstream ? Any other thoughts that helps to test the > > driver ? > > I think that's the best you can do for now. We can probably help with > testing as our stuff gets off the ground. > OK > > Sorry for long email and too many questions, but I thought it is easier > > this way to begin with than throwing huge code implementing loads of APIs > > with no users(expect example partition) especially that I am posting this > > during merge window. > > No problem. Maybe it would help if I described roughly what we were thinking > of doing for KVM (this is open for discussion, of course): > > 1. Describe KVM-managed partitions in the DT, along the lines of [1] > 2. Expose each partition as a file to userspace. E.g.: > > /dev/spci/: > > self > e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8 > 49f65057-d002-4ae2-b4ee-d31c7940a13d > > Here, self would be a symlink to the host uuid. The host uuid file > would implement FFA_MEM operations using an ioctl(), so you could, > for example, share a user buffer with multiple partitions by issuing > a MEM_SHARE ioctl() on self, passing the fds for the borrower partitions > as arguments. Messaging would be implemented as ioctl()s on the > partition uuid files themselves. > OK, IIUC that covers mostly KVM implementation. We still need a way to share the RxTx buffer info to the partitions and DT/ACPI(?) is one possible way. Based on you comment about not needing DT node, do you have any other way to communicate the buffer info to the partitions ? > 3. We'll need some (all?) of these patches to unmap memory from the host > when necessary: > > https://lwn.net/Articles/821215/ > > (for nVHE, we'll have a stage-2 for the host so we can unmap there as > well) > Sounds more fun. > For communicating with partitions that are not managed by KVM (e.g. trusted > applications), it's not clear to me how much of that will be handled in > kernel or user. I think it would still be worth exposing the partitions as > files, but perhaps having them root only or just returning -EPERM for the > ioctl() if a kernel driver has claimed the partition as its own? Ideally, > FF-A would allow us to transition some of the Trusted OS interfacing code > out to userspace, but I don't know how realistic that is. > Ah good, so we can still manage in-kernel users this way but we need to provide interface to such a driver which I agree that we need to avoid if possible. > Anyway, to enable this, I think we need a clear separation in the kernel > between the FF-A code and the users: Agreed. > KVM will want to expose things as above, but if drivers need to use this > stuff as well then they can plug in as additional users and we don't have to > worry about tripping over the RX/TX buffers etc. > I am confused a bit. When you refer drivers above, are you referring to drivers in host kernel(hypervisor) or in the partitions. I fail to imagine need for the former. > What do you think, and do you reckon you can spin a cut-down driver that > implements the common part of the logic (since I know you've written much > of this code already)? > I am not sure if I am aligned with your thoughts on the buffer sharing yet. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface 2020-06-09 17:41 ` Sudeep Holla @ 2020-06-10 7:57 ` Will Deacon -1 siblings, 0 replies; 45+ messages in thread From: Will Deacon @ 2020-06-10 7:57 UTC (permalink / raw) To: Sudeep Holla Cc: devicetree, linux-arm-kernel, linux-kernel, Marc Zyngier, tabba, qwandor, ardb Hi Sudeep, On Tue, Jun 09, 2020 at 06:41:23PM +0100, Sudeep Holla wrote: > On Thu, Jun 04, 2020 at 02:37:46PM +0100, Will Deacon wrote: > > On Mon, Jun 01, 2020 at 10:45:09AM +0100, Sudeep Holla wrote: > > > Sorry for posting in the middle of merge window and I must have done > > > this last week itself. This is not the driver I had thought about posting > > > last week. After I started cleaning up and looking at Will's KVM prototype[1] > > > for PSA FF-A (previously known as SPCI), > > > > Yes, I need to do the Big Rename at some point. Joy. > > > > 😁 Renamed version here: https://android-kvm.googlesource.com/linux/+/refs/heads/willdeacon/psa-ffa although I haven't psyched myself up to write yaml yet. > > Setting the static RX/TX buffer allocation aside, why is a DT node needed > > at all for the case where Linux is running purely as an FF-A client? I > > thought everything should be discoverable via FFA_VERSION, FFA_FEATURES, > > FFA_PARTITION_INFO_GET and FFA_ID_GET? That should mean we can get away > > without a binding at all for the client case. > > > > Agreed, I added for RxTx buffers and initially to build the parent/child > hierarchy for all users of the driver. Initially I was assuming only > in-kernel users and now I agree we should avoid any in kernel users if > possible. > > One thing to note FFA_PARTITION_INFO_GET relies on Rx buffers to send the > information to the caller. So we need to have established buffers before > that and one of the reason you don't find that in this RFC. I dropped that > too which I wanted initially. Ok, sounds like we should at least get to a position where we can enumerate things, though. > > > Sorry for long email and too many questions, but I thought it is easier > > > this way to begin with than throwing huge code implementing loads of APIs > > > with no users(expect example partition) especially that I am posting this > > > during merge window. > > > > No problem. Maybe it would help if I described roughly what we were thinking > > of doing for KVM (this is open for discussion, of course): > > > > 1. Describe KVM-managed partitions in the DT, along the lines of [1] > > 2. Expose each partition as a file to userspace. E.g.: > > > > /dev/spci/: > > > > self > > e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8 > > 49f65057-d002-4ae2-b4ee-d31c7940a13d > > > > Here, self would be a symlink to the host uuid. The host uuid file > > would implement FFA_MEM operations using an ioctl(), so you could, > > for example, share a user buffer with multiple partitions by issuing > > a MEM_SHARE ioctl() on self, passing the fds for the borrower partitions > > as arguments. Messaging would be implemented as ioctl()s on the > > partition uuid files themselves. > > > > OK, IIUC that covers mostly KVM implementation. We still need a way to > share the RxTx buffer info to the partitions and DT/ACPI(?) is one > possible way. Based on you comment about not needing DT node, do you have > any other way to communicate the buffer info to the partitions ? This is only a concern if KVM chooses to provide the Rx/Tx buffer pair though, right? If we punt that down the road for the moment, then we can just rely on FFA_RXTX_MAP for now. > > For communicating with partitions that are not managed by KVM (e.g. trusted > > applications), it's not clear to me how much of that will be handled in > > kernel or user. I think it would still be worth exposing the partitions as > > files, but perhaps having them root only or just returning -EPERM for the > > ioctl() if a kernel driver has claimed the partition as its own? Ideally, > > FF-A would allow us to transition some of the Trusted OS interfacing code > > out to userspace, but I don't know how realistic that is. > > > > Ah good, so we can still manage in-kernel users this way but we need to > provide interface to such a driver which I agree that we need to avoid > if possible. > > > Anyway, to enable this, I think we need a clear separation in the kernel > > between the FF-A code and the users: > Agreed. > > > KVM will want to expose things as above, but if drivers need to use this > > stuff as well then they can plug in as additional users and we don't have to > > worry about tripping over the RX/TX buffers etc. > > > > I am confused a bit. When you refer drivers above, are you referring to > drivers in host kernel(hypervisor) or in the partitions. I fail to > imagine need for the former. I'm referring to in-kernel users in the host kernel. For KVM-managed guests, we may not need these, although signalling things like system shutdown might be better off done without relying on userspace. But my point is really that separating the buffer management from the users means we can serialise consumers, whether they are in-kernel or out in userspace. > > What do you think, and do you reckon you can spin a cut-down driver that > > implements the common part of the logic (since I know you've written much > > of this code already)? > > > > I am not sure if I am aligned with your thoughts on the buffer sharing > yet. Ok, please let me know if you have any more questions. Will ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface @ 2020-06-10 7:57 ` Will Deacon 0 siblings, 0 replies; 45+ messages in thread From: Will Deacon @ 2020-06-10 7:57 UTC (permalink / raw) To: Sudeep Holla Cc: devicetree, qwandor, Marc Zyngier, linux-kernel, linux-arm-kernel, ardb, tabba Hi Sudeep, On Tue, Jun 09, 2020 at 06:41:23PM +0100, Sudeep Holla wrote: > On Thu, Jun 04, 2020 at 02:37:46PM +0100, Will Deacon wrote: > > On Mon, Jun 01, 2020 at 10:45:09AM +0100, Sudeep Holla wrote: > > > Sorry for posting in the middle of merge window and I must have done > > > this last week itself. This is not the driver I had thought about posting > > > last week. After I started cleaning up and looking at Will's KVM prototype[1] > > > for PSA FF-A (previously known as SPCI), > > > > Yes, I need to do the Big Rename at some point. Joy. > > > > 😁 Renamed version here: https://android-kvm.googlesource.com/linux/+/refs/heads/willdeacon/psa-ffa although I haven't psyched myself up to write yaml yet. > > Setting the static RX/TX buffer allocation aside, why is a DT node needed > > at all for the case where Linux is running purely as an FF-A client? I > > thought everything should be discoverable via FFA_VERSION, FFA_FEATURES, > > FFA_PARTITION_INFO_GET and FFA_ID_GET? That should mean we can get away > > without a binding at all for the client case. > > > > Agreed, I added for RxTx buffers and initially to build the parent/child > hierarchy for all users of the driver. Initially I was assuming only > in-kernel users and now I agree we should avoid any in kernel users if > possible. > > One thing to note FFA_PARTITION_INFO_GET relies on Rx buffers to send the > information to the caller. So we need to have established buffers before > that and one of the reason you don't find that in this RFC. I dropped that > too which I wanted initially. Ok, sounds like we should at least get to a position where we can enumerate things, though. > > > Sorry for long email and too many questions, but I thought it is easier > > > this way to begin with than throwing huge code implementing loads of APIs > > > with no users(expect example partition) especially that I am posting this > > > during merge window. > > > > No problem. Maybe it would help if I described roughly what we were thinking > > of doing for KVM (this is open for discussion, of course): > > > > 1. Describe KVM-managed partitions in the DT, along the lines of [1] > > 2. Expose each partition as a file to userspace. E.g.: > > > > /dev/spci/: > > > > self > > e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8 > > 49f65057-d002-4ae2-b4ee-d31c7940a13d > > > > Here, self would be a symlink to the host uuid. The host uuid file > > would implement FFA_MEM operations using an ioctl(), so you could, > > for example, share a user buffer with multiple partitions by issuing > > a MEM_SHARE ioctl() on self, passing the fds for the borrower partitions > > as arguments. Messaging would be implemented as ioctl()s on the > > partition uuid files themselves. > > > > OK, IIUC that covers mostly KVM implementation. We still need a way to > share the RxTx buffer info to the partitions and DT/ACPI(?) is one > possible way. Based on you comment about not needing DT node, do you have > any other way to communicate the buffer info to the partitions ? This is only a concern if KVM chooses to provide the Rx/Tx buffer pair though, right? If we punt that down the road for the moment, then we can just rely on FFA_RXTX_MAP for now. > > For communicating with partitions that are not managed by KVM (e.g. trusted > > applications), it's not clear to me how much of that will be handled in > > kernel or user. I think it would still be worth exposing the partitions as > > files, but perhaps having them root only or just returning -EPERM for the > > ioctl() if a kernel driver has claimed the partition as its own? Ideally, > > FF-A would allow us to transition some of the Trusted OS interfacing code > > out to userspace, but I don't know how realistic that is. > > > > Ah good, so we can still manage in-kernel users this way but we need to > provide interface to such a driver which I agree that we need to avoid > if possible. > > > Anyway, to enable this, I think we need a clear separation in the kernel > > between the FF-A code and the users: > Agreed. > > > KVM will want to expose things as above, but if drivers need to use this > > stuff as well then they can plug in as additional users and we don't have to > > worry about tripping over the RX/TX buffers etc. > > > > I am confused a bit. When you refer drivers above, are you referring to > drivers in host kernel(hypervisor) or in the partitions. I fail to > imagine need for the former. I'm referring to in-kernel users in the host kernel. For KVM-managed guests, we may not need these, although signalling things like system shutdown might be better off done without relying on userspace. But my point is really that separating the buffer management from the users means we can serialise consumers, whether they are in-kernel or out in userspace. > > What do you think, and do you reckon you can spin a cut-down driver that > > implements the common part of the logic (since I know you've written much > > of this code already)? > > > > I am not sure if I am aligned with your thoughts on the buffer sharing > yet. Ok, please let me know if you have any more questions. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface 2020-06-10 7:57 ` Will Deacon @ 2020-06-10 8:10 ` Sudeep Holla -1 siblings, 0 replies; 45+ messages in thread From: Sudeep Holla @ 2020-06-10 8:10 UTC (permalink / raw) To: Will Deacon Cc: devicetree, linux-arm-kernel, linux-kernel, Marc Zyngier, tabba, qwandor, ardb Hi Will, On Wed, Jun 10, 2020 at 08:57:12AM +0100, Will Deacon wrote: > Hi Sudeep, > > On Tue, Jun 09, 2020 at 06:41:23PM +0100, Sudeep Holla wrote: [...] > > > > Agreed, I added for RxTx buffers and initially to build the parent/child > > hierarchy for all users of the driver. Initially I was assuming only > > in-kernel users and now I agree we should avoid any in kernel users if > > possible. > > > > One thing to note FFA_PARTITION_INFO_GET relies on Rx buffers to send the > > information to the caller. So we need to have established buffers before > > that and one of the reason you don't find that in this RFC. I dropped that > > too which I wanted initially. > > Ok, sounds like we should at least get to a position where we can enumerate > things, though. > Yes. [...] > > > > OK, IIUC that covers mostly KVM implementation. We still need a way to > > share the RxTx buffer info to the partitions and DT/ACPI(?) is one > > possible way. Based on you comment about not needing DT node, do you have > > any other way to communicate the buffer info to the partitions ? > > This is only a concern if KVM chooses to provide the Rx/Tx buffer pair > though, right? If we punt that down the road for the moment, then we can > just rely on FFA_RXTX_MAP for now. > Ah OK, I was under the assumption that we didn't want to use FFA_RXTX_{,UN}MAP [...] > > > > I am confused a bit. When you refer drivers above, are you referring to > > drivers in host kernel(hypervisor) or in the partitions. I fail to > > imagine need for the former. > > I'm referring to in-kernel users in the host kernel. For KVM-managed guests, > we may not need these, although signalling things like system shutdown might > be better off done without relying on userspace. But my point is really that > separating the buffer management from the users means we can serialise > consumers, whether they are in-kernel or out in userspace. > Understood. > > > What do you think, and do you reckon you can spin a cut-down driver that > > > implements the common part of the logic (since I know you've written much > > > of this code already)? > > > > > > > I am not sure if I am aligned with your thoughts on the buffer sharing > > yet. > > Ok, please let me know if you have any more questions. > None ATM. As I mentioned I had ruled out RXTX_{,UN}MAP which was my misunderstanding. -- Regards, Sudeep ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface @ 2020-06-10 8:10 ` Sudeep Holla 0 siblings, 0 replies; 45+ messages in thread From: Sudeep Holla @ 2020-06-10 8:10 UTC (permalink / raw) To: Will Deacon Cc: devicetree, qwandor, Marc Zyngier, linux-kernel, linux-arm-kernel, ardb, tabba Hi Will, On Wed, Jun 10, 2020 at 08:57:12AM +0100, Will Deacon wrote: > Hi Sudeep, > > On Tue, Jun 09, 2020 at 06:41:23PM +0100, Sudeep Holla wrote: [...] > > > > Agreed, I added for RxTx buffers and initially to build the parent/child > > hierarchy for all users of the driver. Initially I was assuming only > > in-kernel users and now I agree we should avoid any in kernel users if > > possible. > > > > One thing to note FFA_PARTITION_INFO_GET relies on Rx buffers to send the > > information to the caller. So we need to have established buffers before > > that and one of the reason you don't find that in this RFC. I dropped that > > too which I wanted initially. > > Ok, sounds like we should at least get to a position where we can enumerate > things, though. > Yes. [...] > > > > OK, IIUC that covers mostly KVM implementation. We still need a way to > > share the RxTx buffer info to the partitions and DT/ACPI(?) is one > > possible way. Based on you comment about not needing DT node, do you have > > any other way to communicate the buffer info to the partitions ? > > This is only a concern if KVM chooses to provide the Rx/Tx buffer pair > though, right? If we punt that down the road for the moment, then we can > just rely on FFA_RXTX_MAP for now. > Ah OK, I was under the assumption that we didn't want to use FFA_RXTX_{,UN}MAP [...] > > > > I am confused a bit. When you refer drivers above, are you referring to > > drivers in host kernel(hypervisor) or in the partitions. I fail to > > imagine need for the former. > > I'm referring to in-kernel users in the host kernel. For KVM-managed guests, > we may not need these, although signalling things like system shutdown might > be better off done without relying on userspace. But my point is really that > separating the buffer management from the users means we can serialise > consumers, whether they are in-kernel or out in userspace. > Understood. > > > What do you think, and do you reckon you can spin a cut-down driver that > > > implements the common part of the logic (since I know you've written much > > > of this code already)? > > > > > > > I am not sure if I am aligned with your thoughts on the buffer sharing > > yet. > > Ok, please let me know if you have any more questions. > None ATM. As I mentioned I had ruled out RXTX_{,UN}MAP which was my misunderstanding. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface 2020-06-09 17:41 ` Sudeep Holla @ 2020-06-15 11:38 ` Jens Wiklander -1 siblings, 0 replies; 45+ messages in thread From: Jens Wiklander @ 2020-06-15 11:38 UTC (permalink / raw) To: Sudeep Holla Cc: Will Deacon, devicetree, linux-arm-kernel, linux-kernel, Marc Zyngier, tabba, qwandor, ardb Hi, On Tue, Jun 09, 2020 at 06:41:23PM +0100, Sudeep Holla wrote: > (Sorry for the delay, got distracted with some other bug fix.) > > On Thu, Jun 04, 2020 at 02:37:46PM +0100, Will Deacon wrote: > > Hi Sudeep, [+Fuad, Andrew and Ard] > > > > (To other interested readers: if you haven't seen it, the FF-A spec is here: > > https://static.docs.arm.com/den0077/a/DEN0077A_PSA_Firmware_Framework_Arm_v8-A_1.0_EAC.pdf > > since this discussion makes no sense without that, and a tiny bit of sense > > with it. It used to be called "SPCI" but it was recently renamed.) > > > > Thanks for adding all interested parties. > > > On Mon, Jun 01, 2020 at 10:45:09AM +0100, Sudeep Holla wrote: > > > Sorry for posting in the middle of merge window and I must have done > > > this last week itself. This is not the driver I had thought about posting > > > last week. After I started cleaning up and looking at Will's KVM prototype[1] > > > for PSA FF-A (previously known as SPCI), > > > > Yes, I need to do the Big Rename at some point. Joy. > > > > 😁 > > > > I got more doubts on alignment and dropped huge chunk of interface APIs in > > > the driver in order to keep it simple, and get aligned more with that > > > prototype and avoid scanning lots of code unnecessary. > > > > You also dropped most of the code, so this doesn't really do anything in > > its current form ;) > > > > Yes, it was intentional 😉 > > > > Here are few things to clarify: > > > > > > 1. DT bindings > > > --------------- > > > I was initially against adding bindings for Tx/Rx buffers for > > > partitions. As per the spec, an endpoint could allocate the > > > buffer pair and use the FFA_RXTX_MAP interface to map it with the > > > Hypervisor(KVM here). However looking at the prototype and also > > > I remember you mentioning that it is not possible to manage buffers > > > in that way. Please confirm if you plan to add the buffer details > > > fetcthing them through ioctls in KVM and adding them to VM DT nodes > > > in KVM userspace. I will update the bindings accordingly. > > > > I think it's useful to have a mode of operation where the hypervisor > > allocates the RX/TX buffers and advertises them in the DT. However, we > > can always add this later, so there's no need to have it in the binding > > from the start. Best start as simple as possible, I reckon. > > > > OK > > > Setting the static RX/TX buffer allocation aside, why is a DT node needed > > at all for the case where Linux is running purely as an FF-A client? I > > thought everything should be discoverable via FFA_VERSION, FFA_FEATURES, > > FFA_PARTITION_INFO_GET and FFA_ID_GET? That should mean we can get away > > without a binding at all for the client case. > > > > Agreed, I added for RxTx buffers and initially to build the parent/child > hierarchy for all users of the driver. Initially I was assuming only > in-kernel users and now I agree we should avoid any in kernel users if > possible. > > One thing to note FFA_PARTITION_INFO_GET relies on Rx buffers to send the > information to the caller. So we need to have established buffers before > that and one of the reason you don't find that in this RFC. I dropped that > too which I wanted initially. > > > > 2. Driver > > > --------- > > > a. Support for multiple partitions in a VM > > > ------------------------------------------ > > > I am not sure if there is need for supporting multiple partitions > > > within a VM. It should be possible to do so as I expect to create > > > device for each partition entry under arm-psa-ffa devicetree node. > > > However, I don't want to assume something that will never be a > > > usecase. However I don't think this will change must of the > > > abstraction as we need to keep the interface API implementation > > > separate to support different partitions on various platforms. > > > > I think Ard has a case for something like this, where a VM actually consists > > of multiple partitions so that S-EL0 services can be provided from NS-EL0. > > However, he probably wants that for a dynamically created VM, so we'd > > need a way to instantiate an FFA namespace for the VM. Maybe that can be > > done entirely in userspace by the VMM... > > > > Interesting... > > > > b. SMCCC interface > > > ------------------ > > > This is something I messed up completely while trying to add > > > support for SMCCC v1.2. It now supports x0-x17 as parameter > > > registers(input) and return registers(output). I started simple > > > with x0-x7 as both input and output as PSA FF-A needs that at > > > most. But extending to x0-x17 then became with messy in my > > > implementation. That's the reason I dropped it completely > > > here and thought of checking it first. > > > > > > Do we need to extend the optimisations that were done to handle > > > ARCH_WORKAROUND_{1,2}. Or should be just use a version with x0-x7 > > > as both input and ouput. Hyper-V guys need full x0-x17 support. > > > > > > I need some guidance as what is the approach preferred ? > > > > I think we can start off with x0-x7 and extend if later if we need to. > > > > Sure > > > > 3. Partitions > > > ------------- > > > I am not sure if we have a full define partition that we plan to > > > push upstream. Without one, we can have a sample/example partition > > > to test all the interface APIs, but is that fine with respect to > > > what we want upstream ? Any other thoughts that helps to test the > > > driver ? > > > > I think that's the best you can do for now. We can probably help with > > testing as our stuff gets off the ground. > > > > OK > > > > Sorry for long email and too many questions, but I thought it is easier > > > this way to begin with than throwing huge code implementing loads of APIs > > > with no users(expect example partition) especially that I am posting this > > > during merge window. > > > > No problem. Maybe it would help if I described roughly what we were thinking > > of doing for KVM (this is open for discussion, of course): > > > > 1. Describe KVM-managed partitions in the DT, along the lines of [1] > > 2. Expose each partition as a file to userspace. E.g.: > > > > /dev/spci/: > > > > self > > e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8 > > 49f65057-d002-4ae2-b4ee-d31c7940a13d > > > > Here, self would be a symlink to the host uuid. The host uuid file > > would implement FFA_MEM operations using an ioctl(), so you could, > > for example, share a user buffer with multiple partitions by issuing > > a MEM_SHARE ioctl() on self, passing the fds for the borrower partitions > > as arguments. Messaging would be implemented as ioctl()s on the > > partition uuid files themselves. > > > > OK, IIUC that covers mostly KVM implementation. We still need a way to > share the RxTx buffer info to the partitions and DT/ACPI(?) is one > possible way. Based on you comment about not needing DT node, do you have > any other way to communicate the buffer info to the partitions ? > > > 3. We'll need some (all?) of these patches to unmap memory from the host > > when necessary: > > > > https://lwn.net/Articles/821215/ > > > > (for nVHE, we'll have a stage-2 for the host so we can unmap there as > > well) > > > > Sounds more fun. > > > For communicating with partitions that are not managed by KVM (e.g. trusted > > applications), it's not clear to me how much of that will be handled in > > kernel or user. I think it would still be worth exposing the partitions as > > files, but perhaps having them root only or just returning -EPERM for the > > ioctl() if a kernel driver has claimed the partition as its own? Ideally, > > FF-A would allow us to transition some of the Trusted OS interfacing code > > out to userspace, but I don't know how realistic that is. > > > > Ah good, so we can still manage in-kernel users this way but we need to > provide interface to such a driver which I agree that we need to avoid > if possible. The OP-TEE driver is an in-kernel user, I don't see that we can migrate that to user space in the nearest future. In fact I'm not sure it would make sense since we have a kernel internal interface which is used by some drivers. Cheers, Jens ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface @ 2020-06-15 11:38 ` Jens Wiklander 0 siblings, 0 replies; 45+ messages in thread From: Jens Wiklander @ 2020-06-15 11:38 UTC (permalink / raw) To: Sudeep Holla Cc: devicetree, qwandor, Marc Zyngier, linux-kernel, linux-arm-kernel, Will Deacon, ardb, tabba Hi, On Tue, Jun 09, 2020 at 06:41:23PM +0100, Sudeep Holla wrote: > (Sorry for the delay, got distracted with some other bug fix.) > > On Thu, Jun 04, 2020 at 02:37:46PM +0100, Will Deacon wrote: > > Hi Sudeep, [+Fuad, Andrew and Ard] > > > > (To other interested readers: if you haven't seen it, the FF-A spec is here: > > https://static.docs.arm.com/den0077/a/DEN0077A_PSA_Firmware_Framework_Arm_v8-A_1.0_EAC.pdf > > since this discussion makes no sense without that, and a tiny bit of sense > > with it. It used to be called "SPCI" but it was recently renamed.) > > > > Thanks for adding all interested parties. > > > On Mon, Jun 01, 2020 at 10:45:09AM +0100, Sudeep Holla wrote: > > > Sorry for posting in the middle of merge window and I must have done > > > this last week itself. This is not the driver I had thought about posting > > > last week. After I started cleaning up and looking at Will's KVM prototype[1] > > > for PSA FF-A (previously known as SPCI), > > > > Yes, I need to do the Big Rename at some point. Joy. > > > > 😁 > > > > I got more doubts on alignment and dropped huge chunk of interface APIs in > > > the driver in order to keep it simple, and get aligned more with that > > > prototype and avoid scanning lots of code unnecessary. > > > > You also dropped most of the code, so this doesn't really do anything in > > its current form ;) > > > > Yes, it was intentional 😉 > > > > Here are few things to clarify: > > > > > > 1. DT bindings > > > --------------- > > > I was initially against adding bindings for Tx/Rx buffers for > > > partitions. As per the spec, an endpoint could allocate the > > > buffer pair and use the FFA_RXTX_MAP interface to map it with the > > > Hypervisor(KVM here). However looking at the prototype and also > > > I remember you mentioning that it is not possible to manage buffers > > > in that way. Please confirm if you plan to add the buffer details > > > fetcthing them through ioctls in KVM and adding them to VM DT nodes > > > in KVM userspace. I will update the bindings accordingly. > > > > I think it's useful to have a mode of operation where the hypervisor > > allocates the RX/TX buffers and advertises them in the DT. However, we > > can always add this later, so there's no need to have it in the binding > > from the start. Best start as simple as possible, I reckon. > > > > OK > > > Setting the static RX/TX buffer allocation aside, why is a DT node needed > > at all for the case where Linux is running purely as an FF-A client? I > > thought everything should be discoverable via FFA_VERSION, FFA_FEATURES, > > FFA_PARTITION_INFO_GET and FFA_ID_GET? That should mean we can get away > > without a binding at all for the client case. > > > > Agreed, I added for RxTx buffers and initially to build the parent/child > hierarchy for all users of the driver. Initially I was assuming only > in-kernel users and now I agree we should avoid any in kernel users if > possible. > > One thing to note FFA_PARTITION_INFO_GET relies on Rx buffers to send the > information to the caller. So we need to have established buffers before > that and one of the reason you don't find that in this RFC. I dropped that > too which I wanted initially. > > > > 2. Driver > > > --------- > > > a. Support for multiple partitions in a VM > > > ------------------------------------------ > > > I am not sure if there is need for supporting multiple partitions > > > within a VM. It should be possible to do so as I expect to create > > > device for each partition entry under arm-psa-ffa devicetree node. > > > However, I don't want to assume something that will never be a > > > usecase. However I don't think this will change must of the > > > abstraction as we need to keep the interface API implementation > > > separate to support different partitions on various platforms. > > > > I think Ard has a case for something like this, where a VM actually consists > > of multiple partitions so that S-EL0 services can be provided from NS-EL0. > > However, he probably wants that for a dynamically created VM, so we'd > > need a way to instantiate an FFA namespace for the VM. Maybe that can be > > done entirely in userspace by the VMM... > > > > Interesting... > > > > b. SMCCC interface > > > ------------------ > > > This is something I messed up completely while trying to add > > > support for SMCCC v1.2. It now supports x0-x17 as parameter > > > registers(input) and return registers(output). I started simple > > > with x0-x7 as both input and output as PSA FF-A needs that at > > > most. But extending to x0-x17 then became with messy in my > > > implementation. That's the reason I dropped it completely > > > here and thought of checking it first. > > > > > > Do we need to extend the optimisations that were done to handle > > > ARCH_WORKAROUND_{1,2}. Or should be just use a version with x0-x7 > > > as both input and ouput. Hyper-V guys need full x0-x17 support. > > > > > > I need some guidance as what is the approach preferred ? > > > > I think we can start off with x0-x7 and extend if later if we need to. > > > > Sure > > > > 3. Partitions > > > ------------- > > > I am not sure if we have a full define partition that we plan to > > > push upstream. Without one, we can have a sample/example partition > > > to test all the interface APIs, but is that fine with respect to > > > what we want upstream ? Any other thoughts that helps to test the > > > driver ? > > > > I think that's the best you can do for now. We can probably help with > > testing as our stuff gets off the ground. > > > > OK > > > > Sorry for long email and too many questions, but I thought it is easier > > > this way to begin with than throwing huge code implementing loads of APIs > > > with no users(expect example partition) especially that I am posting this > > > during merge window. > > > > No problem. Maybe it would help if I described roughly what we were thinking > > of doing for KVM (this is open for discussion, of course): > > > > 1. Describe KVM-managed partitions in the DT, along the lines of [1] > > 2. Expose each partition as a file to userspace. E.g.: > > > > /dev/spci/: > > > > self > > e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8 > > 49f65057-d002-4ae2-b4ee-d31c7940a13d > > > > Here, self would be a symlink to the host uuid. The host uuid file > > would implement FFA_MEM operations using an ioctl(), so you could, > > for example, share a user buffer with multiple partitions by issuing > > a MEM_SHARE ioctl() on self, passing the fds for the borrower partitions > > as arguments. Messaging would be implemented as ioctl()s on the > > partition uuid files themselves. > > > > OK, IIUC that covers mostly KVM implementation. We still need a way to > share the RxTx buffer info to the partitions and DT/ACPI(?) is one > possible way. Based on you comment about not needing DT node, do you have > any other way to communicate the buffer info to the partitions ? > > > 3. We'll need some (all?) of these patches to unmap memory from the host > > when necessary: > > > > https://lwn.net/Articles/821215/ > > > > (for nVHE, we'll have a stage-2 for the host so we can unmap there as > > well) > > > > Sounds more fun. > > > For communicating with partitions that are not managed by KVM (e.g. trusted > > applications), it's not clear to me how much of that will be handled in > > kernel or user. I think it would still be worth exposing the partitions as > > files, but perhaps having them root only or just returning -EPERM for the > > ioctl() if a kernel driver has claimed the partition as its own? Ideally, > > FF-A would allow us to transition some of the Trusted OS interfacing code > > out to userspace, but I don't know how realistic that is. > > > > Ah good, so we can still manage in-kernel users this way but we need to > provide interface to such a driver which I agree that we need to avoid > if possible. The OP-TEE driver is an in-kernel user, I don't see that we can migrate that to user space in the nearest future. In fact I'm not sure it would make sense since we have a kernel internal interface which is used by some drivers. Cheers, Jens _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2020-07-09 22:17 UTC | newest] Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-06-01 9:45 [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface Sudeep Holla 2020-06-01 9:45 ` Sudeep Holla 2020-06-01 9:45 ` [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions Sudeep Holla 2020-06-01 9:45 ` Sudeep Holla 2020-06-09 22:35 ` Rob Herring 2020-06-09 22:35 ` Rob Herring 2020-06-10 7:43 ` Will Deacon 2020-06-10 7:43 ` Will Deacon 2020-06-10 13:56 ` Rob Herring 2020-06-10 13:56 ` Rob Herring 2020-06-11 15:46 ` Achin Gupta 2020-06-11 15:46 ` Achin Gupta 2020-06-11 17:12 ` Will Deacon 2020-06-11 17:12 ` Will Deacon 2020-06-15 9:16 ` Achin Gupta 2020-06-15 9:16 ` Achin Gupta 2020-06-15 9:51 ` Will Deacon 2020-06-15 9:51 ` Will Deacon 2020-06-15 11:42 ` Achin Gupta 2020-06-15 11:42 ` Achin Gupta 2020-06-15 11:55 ` Will Deacon 2020-06-15 11:55 ` Will Deacon 2020-06-15 16:48 ` Achin Gupta 2020-06-15 16:48 ` Achin Gupta 2020-06-10 8:32 ` Sudeep Holla 2020-06-10 8:32 ` Sudeep Holla 2020-06-01 9:45 ` [RFC PATCH 2/3] firmware: Add support for PSA FF-A transport for " Sudeep Holla 2020-06-01 9:45 ` Sudeep Holla 2020-06-01 13:46 ` kbuild test robot 2020-06-02 7:11 ` kbuild test robot 2020-07-09 22:15 ` Arve Hjønnevåg 2020-07-09 22:15 ` Arve Hjønnevåg 2020-06-01 9:45 ` [RFC PATCH 3/3] firmware: Add example PSA FF-A non-secure VM partition Sudeep Holla 2020-06-01 9:45 ` Sudeep Holla 2020-06-01 14:22 ` kbuild test robot 2020-06-04 13:37 ` [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface Will Deacon 2020-06-04 13:37 ` Will Deacon 2020-06-09 17:41 ` Sudeep Holla 2020-06-09 17:41 ` Sudeep Holla 2020-06-10 7:57 ` Will Deacon 2020-06-10 7:57 ` Will Deacon 2020-06-10 8:10 ` Sudeep Holla 2020-06-10 8:10 ` Sudeep Holla 2020-06-15 11:38 ` Jens Wiklander 2020-06-15 11:38 ` Jens Wiklander
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.