| Message ID | 20201103174350.991593-1-sudeep.holla@arm.com |
|---|---|
| Headers | show |
| Series | firmware: Add initial support for Arm FF-A | expand |
Hi Sudeep, On Tue, Nov 03, 2020 at 05:43:41PM +0000, Sudeep Holla wrote: > Hi all, > > Let me start stating this is just initial implementation to check on > the idea of providing more in-kernel and userspace support. Lot of things > are still work in progress, I am posting just to get the early feedback > before building lot of things on this idea. Consider this more as RFC > though not tagged explicity(just to avoid it being ignored :)) > > Arm Firmware Framework for Armv8-A specification[1] describes a software > architecture that provides mechanism to utilise the virtualization > extension to isolate software images and describes interfaces that > standardize communication between the various software images. This > includes communication between images in the Secure and Normal world. > > The main idea here is to create FFA device to establish any communication > with a partition(secure or normal world VM). > > If it is a partition managed by hypervisor, then we will register chardev > associated with each of those partition FFA device. > > /dev/arm_ffa: > > e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8 > 49f65057-d002-4ae2-b4ee-d31c7940a13d > > For in-kernel usage(mostly communication with secure partitions), only > in-kernel APIs are accessible(no userspace). There may be a need to > provide userspace access instead of in-kernel, it is not yet support > in this series as we need way to identify those and I am not sure if > that belong to DT. With unfiltered VM to VM commnication from user space there's no easy way for two VMs to exchange privileged information that excludes user space. Perhaps access to the FFA device is considered privileged and enough for all purposes. If I've understood it correctly is VM to SP communication only allowed via kernel mode in the VM. The communication with OP-TEE depends on this with the recent commit c5b4312bea5d ("tee: optee: Add support for session login client UUID generation"). Cheers, Jens
On Sat, Nov 28, 2020 at 01:25:02PM +0100, Jens Wiklander wrote: > Hi Sudeep, > > On Tue, Nov 03, 2020 at 05:43:41PM +0000, Sudeep Holla wrote: > > Hi all, > > > > Let me start stating this is just initial implementation to check on > > the idea of providing more in-kernel and userspace support. Lot of things > > are still work in progress, I am posting just to get the early feedback > > before building lot of things on this idea. Consider this more as RFC > > though not tagged explicity(just to avoid it being ignored :)) > > > > Arm Firmware Framework for Armv8-A specification[1] describes a software > > architecture that provides mechanism to utilise the virtualization > > extension to isolate software images and describes interfaces that > > standardize communication between the various software images. This > > includes communication between images in the Secure and Normal world. > > > > The main idea here is to create FFA device to establish any communication > > with a partition(secure or normal world VM). > > > > If it is a partition managed by hypervisor, then we will register chardev > > associated with each of those partition FFA device. > > > > /dev/arm_ffa: > > > > e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8 > > 49f65057-d002-4ae2-b4ee-d31c7940a13d > > > > For in-kernel usage(mostly communication with secure partitions), only > > in-kernel APIs are accessible(no userspace). There may be a need to > > provide userspace access instead of in-kernel, it is not yet support > > in this series as we need way to identify those and I am not sure if > > that belong to DT. > > With unfiltered VM to VM commnication from user space there's no easy > way for two VMs to exchange privileged information that excludes user > space. Though this usercase is dropped now, it was targeted for VMM and may be it was not an issue there. > Perhaps access to the FFA device is considered privileged and > enough for all purposes. > I don't know TBH. > If I've understood it correctly is VM to SP communication only allowed > via kernel mode in the VM. Correct. > The communication with OP-TEE depends on this with the recent commit > c5b4312bea5d ("tee: optee: Add support for session login client UUID > generation"). > OK, thanks for the info. -- Regards, Sudeep
Hi all, Let me start stating this is just initial implementation to check on the idea of providing more in-kernel and userspace support. Lot of things are still work in progress, I am posting just to get the early feedback before building lot of things on this idea. Consider this more as RFC though not tagged explicity(just to avoid it being ignored :)) Arm Firmware Framework for Armv8-A specification[1] describes a software architecture that provides mechanism to utilise the virtualization extension to isolate software images and describes interfaces that standardize communication between the various software images. This includes communication between images in the Secure and Normal world. The main idea here is to create FFA device to establish any communication with a partition(secure or normal world VM). If it is a partition managed by hypervisor, then we will register chardev associated with each of those partition FFA device. /dev/arm_ffa: e3a48fa5-dc54-4a8b-898b-bdc4dfeeb7b8 49f65057-d002-4ae2-b4ee-d31c7940a13d For in-kernel usage(mostly communication with secure partitions), only in-kernel APIs are accessible(no userspace). There may be a need to provide userspace access instead of in-kernel, it is not yet support in this series as we need way to identify those and I am not sure if that belong to DT. -- Regards, Sudeep [1] https://developer.arm.com/documentation/den0077/latest v1->v2: - Moved userspace code to a separate unit, will move to separate module. Still working on minimizing initcall dependencies and exported functions to reuse some of the code. - Fixed couple of minor issues pointed out - Dropped ASYNC send message as I haven't been able to test Sudeep Holla (8): dt-bindings: Arm: Extend FF-A binding to support in-kernel usage of partitions arm64: smccc: Add support for SMCCCv1.2 input/output registers firmware: arm_ffa: Add initial FFA bus support for device enumeration firmware: arm_ffa: Add initial Arm FFA driver support firmware: arm_ffa: Add support for SMCCC as transport to FFA driver firmware: arm_ffa: Setup in-kernel users of FFA partitions firmware: arm_ffa: Setup and register all the KVM managed partitions firmware: arm_ffa: Add support for MEM_* interfaces Will Deacon (1): dt-bindings: Arm: Add Firmware Framework for Armv8-A (FF-A) binding .../devicetree/bindings/arm/arm,ffa-hyp.yaml | 102 +++ .../devicetree/bindings/arm/arm,ffa.yaml | 58 ++ .../reserved-memory/arm,ffa-memory.yaml | 71 ++ arch/arm64/kernel/asm-offsets.c | 4 + arch/arm64/kernel/smccc-call.S | 22 + drivers/firmware/Kconfig | 1 + drivers/firmware/Makefile | 1 + drivers/firmware/arm_ffa/Kconfig | 21 + drivers/firmware/arm_ffa/Makefile | 6 + drivers/firmware/arm_ffa/bus.c | 199 +++++ drivers/firmware/arm_ffa/common.h | 35 + drivers/firmware/arm_ffa/driver.c | 737 ++++++++++++++++++ drivers/firmware/arm_ffa/hyp_partitions.c | 132 ++++ drivers/firmware/arm_ffa/smccc.c | 54 ++ include/linux/arm-smccc.h | 50 ++ include/linux/arm_ffa.h | 310 ++++++++ include/uapi/linux/arm_ffa.h | 67 ++ 17 files changed, 1870 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/arm,ffa-hyp.yaml create mode 100644 Documentation/devicetree/bindings/arm/arm,ffa.yaml create mode 100644 Documentation/devicetree/bindings/reserved-memory/arm,ffa-memory.yaml create mode 100644 drivers/firmware/arm_ffa/Kconfig create mode 100644 drivers/firmware/arm_ffa/Makefile create mode 100644 drivers/firmware/arm_ffa/bus.c create mode 100644 drivers/firmware/arm_ffa/common.h create mode 100644 drivers/firmware/arm_ffa/driver.c create mode 100644 drivers/firmware/arm_ffa/hyp_partitions.c create mode 100644 drivers/firmware/arm_ffa/smccc.c create mode 100644 include/linux/arm_ffa.h create mode 100644 include/uapi/linux/arm_ffa.h -- 2.25.1