Hi all,
This is very basic implementation for in-kernel support for Arm FF-A
specification.
iArm 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 secure partition. This is currently tested with OPTEE(with changes
to OPTEE driver adding FFA as transport)
The series can be fetched from [2]
--
Regards,
Sudeep
[1] https://developer.arm.com/documentation/den0077/latest
[2] git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git v5.11/ffa
v3->v4:
- Added support to allow partitions to set 32bit only mode
- Addressed all the comments from Jens Wiklander
v2->v3:
- Dropped hypervisor partitions and userspace support as it is
no longer in the list of requirements
- Moved away from ioctl style interface for in-kernel users as
there is no need to keep in sync with userspace anymore
- Some kerneldoc fixes as pointed out in earlier reviews
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 (7):
dt-bindings: Arm: Add Firmware Framework for Armv8-A (FF-A) binding
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: Add support for MEM_* interfaces
.../devicetree/bindings/arm/arm,ffa.yaml | 58 ++
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 | 181 +++++
drivers/firmware/arm_ffa/common.h | 32 +
drivers/firmware/arm_ffa/driver.c | 669 ++++++++++++++++++
drivers/firmware/arm_ffa/smccc.c | 54 ++
include/linux/arm-smccc.h | 50 ++
include/linux/arm_ffa.h | 277 ++++++++
13 files changed, 1376 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/arm,ffa.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/smccc.c
create mode 100644 include/linux/arm_ffa.h
--
2.25.1
Since the FF-A v1.0 specification doesn't list the UUID of all the
partitions in the discovery API, we need to specify the UUID of the
partitions that need to be accessed by drivers within the kernel.
This binding to provide the list of partitions that kernel drivers
may need to access.
Signed-off-by: Sudeep Holla <redacted>
---
.../devicetree/bindings/arm/arm,ffa.yaml | 58 +++++++++++++++++++
1 file changed, 58 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/arm,ffa.yaml
Hi Rob,
Sorry to send the same version again just to keep the driver review progress.
I am still exploring on how to add "format: uuid" support in the dt-schemas.
I am seeing errors as format is used in some of the audio/video DT bindings.
I get errors for all those files, may be I need to use $format, initial
trial to do that also failed.
Regarding other comment, I had replied earlier[1] as why we need to keep
separate DT nodes for each partitions.
[1] https://lore.kernel.org/linux-arm-kernel/20210113100011.bnn75jogx22cgkk4@bogus/
Regards,
Sudeep
@@ -0,0 +1,58 @@+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)+%YAML1.2+---+$id:http://devicetree.org/schemas/arm/arm,ffa.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:Arm Firmware Framework for Arm v8-A (in-kernel users)++maintainers:+-Sudeep Holla <sudeep.holla@arm.com>++description:|+Firmware frameworks implementing partition according to the FF-A+specification defined by ARM document number ARM DEN 0077A ("Arm Firmware+Framework for Arm v8-A") [0], providing services to be used by other+partitions.++[0]https://developer.arm.com/docs/den0077/latest++properties:+$nodename:+const:ffa++compatible:+oneOf:+-const:arm,ffa-1.0++patternProperties:+"^ffa_partition[0-9]+$":+type:object+description:One or more child nodes, each describing an FFA partition.+properties:+$nodename:+const:ffa_partition++compatible:+oneOf:+-const:arm,ffa-1.0-partition++uuid:+$ref:'/schemas/types.yaml#definitions/string'+description:|+The 128-bit UUID [2] of the service implemented by this partition.++[2]https://tools.ietf.org/html/rfc4122++additionalProperties:false++examples:+-|+ffa {+compatible = "arm,ffa-1.0";++ffa_partition0 {+compatible = "arm,ffa-1.0-partition";+uuid = "12345678-9abc-def0-1234-56789abcdef0";+};+};
SMCCC v1.2 allows x8-x17 to be used as parameter registers and x4—x17
to be used as result registers in SMC64/HVC64. Arm Firmware Framework
for Armv8-A specification makes use of x0-x7 as parameter and result
registers.
Current SMCCC interface in the kernel just use x0-x7 as parameter and
x0-x3 as result registers. Let us add new interface to support x0-x7
as parameter and result registers. This can be extended to include
x8-x17 when there are users for the same.
Signed-off-by: Sudeep Holla <redacted>
---
arch/arm64/kernel/asm-offsets.c | 4 +++
arch/arm64/kernel/smccc-call.S | 22 +++++++++++++++
include/linux/arm-smccc.h | 50 +++++++++++++++++++++++++++++++++
3 files changed, 76 insertions(+)
@@ -155,6 +155,56 @@ struct arm_smccc_res {unsignedlonga3;};+#ifdef CONFIG_ARM64+/* TODO Need to implement for ARM too */+/**+*structarm_smccc_v1_2_res-ResultfromSMC/HVCcall+*@a0-a7resultvaluesfromregisters0to7+*/+structarm_smccc_v1_2_res{+unsignedlonga0;+unsignedlonga1;+unsignedlonga2;+unsignedlonga3;+unsignedlonga4;+unsignedlonga5;+unsignedlonga6;+unsignedlonga7;+};++/**+*arm_smccc_v1_2_hvc()-makeHVCcalls+*@a0-a7:argumentspassedinregisters0to7+*@res:resultvaluesfromregisters0to7+*+*ThisfunctionisusedtomakeHVCcallsfollowingSMCCallingConvention+*v1.2orabove.Thecontentofthesuppliedparamarecopiedtoregisters+*0to7priortotheHVCinstruction.Thereturnvaluesareupdatedwith+*thecontentfromregister0to7onreturnfromtheHVCinstruction.+*/+asmlinkage+voidarm_smccc_v1_2_hvc(unsignedlonga0,unsignedlonga1,unsignedlonga2,+unsignedlonga3,unsignedlonga4,unsignedlonga5,+unsignedlonga6,unsignedlonga7,+structarm_smccc_v1_2_res*res);++/**+*arm_smccc_v1_2_smc()-makeSMCcalls+*@a0-a7:argumentspassedinregisters0to7+*@res:resultvaluesfromregisters0to7+*+*ThisfunctionisusedtomakeSMCcallsfollowingSMCCallingConvention+*v1.2orabove.Thecontentofthesuppliedparamarecopiedtoregisters+*0to7priortotheSMCinstruction.Thereturnvaluesareupdatedwith+*thecontentfromregister0to7onreturnfromtheSMCinstruction.+*/+asmlinkage+voidarm_smccc_v1_2_smc(unsignedlonga0,unsignedlonga1,unsignedlonga2,+unsignedlonga3,unsignedlonga4,unsignedlonga5,+unsignedlonga6,unsignedlonga7,+structarm_smccc_v1_2_res*res);+#endif+/***structarm_smccc_quirk-Containsquirkinformation*@id:quirkidentification
The Arm FF for Armv8-A specification has concept of endpoints or
partitions. In the Normal world, a partition could be a VM when
the Virtualization extension is enabled or the kernel itself.
In order to handle multiple partitions, we can create a FFA device for
each such partition on a dedicated FFA bus. Similarly, different drivers
requiring FFA transport can be registered on the same bus. We can match
the device and drivers using UUID. This is mostly for the in-kernel
users with FFA drivers.
Signed-off-by: Sudeep Holla <redacted>
---
drivers/firmware/Kconfig | 1 +
drivers/firmware/Makefile | 1 +
drivers/firmware/arm_ffa/Kconfig | 16 +++
drivers/firmware/arm_ffa/Makefile | 4 +
drivers/firmware/arm_ffa/bus.c | 187 ++++++++++++++++++++++++++++++
include/linux/arm_ffa.h | 91 +++++++++++++++
6 files changed, 300 insertions(+)
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 include/linux/arm_ffa.h
This just add a basic driver that sets up the transport(e.g. SMCCC),
checks the FFA version implemented, get the partition ID for self and
sets up the Tx/Rx buffers for communication.
Signed-off-by: Sudeep Holla <redacted>
---
drivers/firmware/arm_ffa/Makefile | 3 +-
drivers/firmware/arm_ffa/bus.c | 14 +-
drivers/firmware/arm_ffa/common.h | 26 +++
drivers/firmware/arm_ffa/driver.c | 297 ++++++++++++++++++++++++++++++
4 files changed, 329 insertions(+), 11 deletions(-)
create mode 100644 drivers/firmware/arm_ffa/common.h
create mode 100644 drivers/firmware/arm_ffa/driver.c
There are requests to keep the transport separate in order to allow
other possible transports like virtio. So let us keep the SMCCC transport
specific routines abstracted.
It is kept simple for now. Once we add another transport, we can develop
better abstraction.
Signed-off-by: Sudeep Holla <redacted>
---
drivers/firmware/arm_ffa/Kconfig | 5 +++
drivers/firmware/arm_ffa/Makefile | 3 +-
drivers/firmware/arm_ffa/common.h | 4 +++
drivers/firmware/arm_ffa/smccc.c | 54 +++++++++++++++++++++++++++++++
4 files changed, 65 insertions(+), 1 deletion(-)
create mode 100644 drivers/firmware/arm_ffa/smccc.c
Parse the FFA nodes from the device-tree and register all the partitions
whose services will be used in the kernel.
In order to also enable in-kernel users of FFA interface, let us add
simple set of operations for such devices.
The in-kernel users are registered without the character device interface.
Signed-off-by: Sudeep Holla <redacted>
---
drivers/firmware/arm_ffa/common.h | 2 +
drivers/firmware/arm_ffa/driver.c | 188 ++++++++++++++++++++++++++++++
include/linux/arm_ffa.h | 38 +++++-
3 files changed, 227 insertions(+), 1 deletion(-)
@@ -182,6 +186,20 @@ static int ffa_version_check(u32 *version)return0;}+staticintffa_rx_release(void)+{+ffa_res_tret;++ret=invoke_ffa_fn(FFA_RX_RELEASE,0,0,0,0,0,0,0);++if(ret.a0==FFA_ERROR)+returnffa_to_linux_errno((int)ret.a2);++/* check for ret.a0 == FFA_RX_RELEASE ? */++return0;+}+staticintffa_rxtx_map(phys_addr_ttx_buf,phys_addr_trx_buf,u32pg_cnt){ffa_res_tret;
@@ -206,6 +224,52 @@ static int ffa_rxtx_unmap(u16 vm_id)return0;}+/* buffer must be sizeof(struct ffa_partition_info) * num_partitions */+staticint+__ffa_partition_info_get(u32uuid0,u32uuid1,u32uuid2,u32uuid3,+structffa_partition_info**buffer,intnum_partitions)+{+intcount;+ffa_res_tpartition_info;++mutex_lock(&drv_info->rx_lock);+partition_info=invoke_ffa_fn(FFA_PARTITION_INFO_GET,uuid0,uuid1,+uuid2,uuid3,0,0,0);++if(partition_info.a0==FFA_ERROR)+returnffa_to_linux_errno((int)partition_info.a2);++count=partition_info.a2;++if(buffer&&count<=num_partitions)+memcpy(*buffer,drv_info->rx_buffer,sizeof(*buffer)*count);++ffa_rx_release();++mutex_unlock(&drv_info->rx_lock);++returncount;+}++staticintffa_partition_probe(constchar*uuid_str,+structffa_partition_info*buffer)+{+intcount;+uuid_tuuid;+u32uuid0_4[4]={0};++if(uuid_parse(uuid_str,&uuid)){+pr_err("invalid uuid (%s)\n",uuid_str);+return-ENODEV;+}++export_uuid((u8*)uuid0_4,&uuid);+count=__ffa_partition_info_get(uuid0_4[0],uuid0_4[1],uuid0_4[2],+uuid0_4[3],&buffer,1);++returncount!=1;+}+#define VM_ID_MASK GENMASK(15, 0)staticintffa_id_get(u16*vm_id){
@@ -221,9 +285,125 @@ static int ffa_id_get(u16 *vm_id)return0;}+staticintffa_msg_send_direct_req(u16src_id,u16dst_id,boolmode_32bit,+structffa_send_direct_data*data)+{+u32req_id,resp_id,src_dst_ids=PACK_TARGET_INFO(src_id,dst_id);+ffa_res_tret;++if(mode_32bit){+req_id=FFA_MSG_SEND_DIRECT_REQ;+resp_id=FFA_MSG_SEND_DIRECT_RESP;+}else{+req_id=FFA_FN_NATIVE(MSG_SEND_DIRECT_REQ);+resp_id=FFA_FN_NATIVE(MSG_SEND_DIRECT_RESP);+}++ret=invoke_ffa_fn(req_id,src_dst_ids,0,data->data0,data->data1,+data->data2,data->data3,data->data4);++while(ret.a0==FFA_INTERRUPT)+ret=invoke_ffa_fn(FFA_RUN,ret.a1,0,0,0,0,0,0);+if(ret.a0==FFA_ERROR)+returnffa_to_linux_errno((int)ret.a2);++if(ret.a0==resp_id){+data->data0=ret.a3;+data->data1=ret.a4;+data->data2=ret.a5;+data->data3=ret.a6;+data->data4=ret.a7;+}++return0;+}++staticu32ffa_api_version_get(void)+{+returndrv_info->version;+}++staticintffa_partition_info_get(constchar*uuid_str,+structffa_partition_info*buffer)+{+if(ffa_partition_probe(uuid_str,buffer))+return-ENOENT;+return0;+}++staticvoidffa_mode_32bit_set(structffa_device*dev)+{+dev->mode_32bit=true;+}++staticintffa_sync_send_receive(structffa_device*dev,+structffa_send_direct_data*data)+{+returnffa_msg_send_direct_req(drv_info->vm_id,dev->vm_id,+dev->mode_32bit,data);+}++staticconststructffa_dev_opsffa_ops={+.api_version_get=ffa_api_version_get,+.partition_info_get=ffa_partition_info_get,+.mode_32bit_set=ffa_mode_32bit_set,+.sync_send_receive=ffa_sync_send_receive,+};++conststructffa_dev_ops*ffa_dev_ops_get(structffa_device*dev)+{+if(ffa_device_is_valid(dev))+return&ffa_ops;++returnNULL;+}+EXPORT_SYMBOL_GPL(ffa_dev_ops_get);++staticvoidffa_setup_partitions(structdevice_node*np)+{+intret;+structdevice_node*child;+structffa_device*ffa_dev;+structffa_partition_infopbuf;+constchar*p_uuid,*pfx="Ignoring FFA partition";+uuid_tuuid=UUID_INIT(0,0,0,0,0,0,0,0,0,0,0);++for_each_child_of_node(np,child){+if(!of_device_is_compatible(child,"arm,ffa-1.0-partition"))+continue;++if(of_property_read_string(child,"uuid",&p_uuid)){+pr_err("%s: failed to parse \"uuid\" property\n",pfx);+continue;+}++if(uuid_parse(p_uuid,&uuid)){+pr_err("%s: invalid \"uuid\" property (%s)\n",+pfx,p_uuid);+continue;+}++ret=ffa_partition_probe(p_uuid,&pbuf);+if(ret){+pr_err("%s: %s partition info probe failed\n",+pfx,p_uuid);+continue;+}++ffa_dev=ffa_device_register(p_uuid,pbuf.id);+if(!ffa_dev){+pr_err("%s: failed to register %s\n",pfx,p_uuid);+continue;+}++ffa_dev_set_drvdata(ffa_dev,drv_info);+}+}+staticint__initffa_init(void){intret;+structdevice_node*np;ret=arm_ffa_bus_init();if(ret)
@@ -270,6 +450,14 @@ static int __init ffa_init(void)mutex_init(&drv_info->rx_lock);mutex_init(&drv_info->tx_lock);+/* Set up all the partitions */+np=of_find_compatible_node(NULL,NULL,"arm,ffa-1.0");+if(!np)+return0;++ffa_setup_partitions(np);+of_node_put(np);+return0;free_pages:if(drv_info->tx_buffer)
@@ -88,4 +93,35 @@ bool ffa_device_is_valid(struct ffa_device *ffa_dev) { return false; }#define module_ffa_driver(__ffa_driver) \module_driver(__ffa_driver,ffa_register,ffa_unregister)+/* FFA transport related */+structffa_partition_info{+u16id;+u16exec_ctxt;+/* partition supports receipt of direct requests */+#define FFA_PARTITION_DIRECT_RECV BIT(0)+/* partition can send direct requests. */+#define FFA_PARTITION_DIRECT_SEND BIT(1)+/* partition can send and receive indirect messages. */+#define FFA_PARTITION_INDIRECT_MSG BIT(2)+u32properties;+};++/* For use with FFA_MSG_SEND_DIRECT_{REQ,RESP} which pass data via registers */+structffa_send_direct_data{+unsignedlongdata0;/* w3/x3 */+unsignedlongdata1;/* w4/x4 */+unsignedlongdata2;/* w5/x5 */+unsignedlongdata3;/* w6/x6 */+unsignedlongdata4;/* w7/x7 */+};++structffa_dev_ops{+u32(*api_version_get)(void);+int(*partition_info_get)(constchar*uuid_str,+structffa_partition_info*buffer);+void(*mode_32bit_set)(structffa_device*dev);+int(*sync_send_receive)(structffa_device*dev,+structffa_send_direct_data*data);+};+#endif /* _LINUX_ARM_FFA_H */
Most of the MEM_* APIs share the same parameters, so they can be
generalised. Currently only MEM_SHARE is implemented and the user space
interface for that is not added yet.
Signed-off-by: Sudeep Holla <redacted>
---
drivers/firmware/arm_ffa/driver.c | 184 ++++++++++++++++++++++++++++++
include/linux/arm_ffa.h | 150 ++++++++++++++++++++++++
2 files changed, 334 insertions(+)
@@ -115,6 +115,153 @@ struct ffa_send_direct_data {unsignedlongdata4;/* w7/x7 */};+structffa_mem_region_addr_range{+/* The base IPA of the constituent memory region, aligned to 4 kiB */+u64address;+/* The number of 4 kiB pages in the constituent memory region. */+u32pg_cnt;+u32reserved;+};++structffa_composite_mem_region{+/*+*Thetotalnumberof4kiBpagesincludedinthismemoryregion.This+*mustbeequaltothesumofpagecountsspecifiedineach+*`structffa_mem_region_addr_range`.+*/+u32total_pg_cnt;+/* The number of constituents included in this memory region range */+u32addr_range_cnt;+u64reserved;+/** An array of `addr_range_cnt` memory region constituents. */+structffa_mem_region_addr_rangeconstituents[];+};++structffa_mem_region_attributes{+/* The ID of the VM to which the memory is being given or shared. */+u16receiver;+/*+*Thepermissionswithwhichthememoryregionshouldbemappedinthe+*receiver'spagetable.+*/+#define FFA_MEM_EXEC BIT(3)+#define FFA_MEM_NO_EXEC BIT(2)+#define FFA_MEM_RW BIT(1)+#define FFA_MEM_RO BIT(0)+u8attrs;+/*+*FlagsusedduringFFA_MEM_RETRIEVE_REQandFFA_MEM_RETRIEVE_RESP+*formemoryregionswithmultipleborrowers.+*/+#define FFA_MEM_RETRIEVE_SELF_BORROWER BIT(0)+u8flag;+u32composite_off;+/*+*Offsetinbytesfromthestartoftheouter`ffa_memory_region`to+*an`structffa_mem_region_addr_range`.+*/+u64reserved;+};++structffa_mem_region{+/* The ID of the VM/owner which originally sent the memory region */+u16sender_id;+#define FFA_MEM_NORMAL BIT(5)+#define FFA_MEM_DEVICE BIT(4)++#define FFA_MEM_WRITE_BACK (3 << 2)+#define FFA_MEM_NON_CACHEABLE (1 << 2)++#define FFA_DEV_nGnRnE (0 << 2)+#define FFA_DEV_nGnRE (1 << 2)+#define FFA_DEV_nGRE (2 << 2)+#define FFA_DEV_GRE (3 << 2)++#define FFA_MEM_NON_SHAREABLE (0)+#define FFA_MEM_OUTER_SHAREABLE (2)+#define FFA_MEM_INNER_SHAREABLE (3)+u8attributes;+u8reserved_0;+/*+*Clearmemoryregioncontentsafterunmappingitfromthesenderand+*beforemappingitforanyreceiver.+*/+#define FFA_MEM_CLEAR BIT(0)+/*+*Whetherthehypervisormaytimeslicethememorysharingorretrieval+*operation.+*/+#define FFA_TIME_SLICE_ENABLE BIT(1)++/*+*Whetherthehypervisorshouldclearthememoryregionbeforethereceiver+*relinquishesitorisaborted.+*/+#define FFA_MEM_CLEAR_BEFORE_RELINQUISH BIT(0)+/*+*Whetherthehypervisorshouldclearthememoryregionafterthereceiver+*relinquishesitorisaborted.+*/+#define FFA_MEM_CLEAR_AFTER_RELINQUISH BIT(2)++#define FFA_MEM_RETRIEVE_TYPE_IN_RESP (0 << 3)+#define FFA_MEM_RETRIEVE_TYPE_SHARE (1 << 3)+#define FFA_MEM_RETRIEVE_TYPE_LEND (2 << 3)+#define FFA_MEM_RETRIEVE_TYPE_DONATE (3 << 3)++#define FFA_MEM_RETRIEVE_ADDR_ALIGN_HINT BIT(9)+#define FFA_MEM_RETRIEVE_ADDR_ALIGN(x) ((x) << 5)+/* Flags to control behaviour of the transaction. */+u32flags;+#define HANDLE_LOW_MASK GENMASK_ULL(31, 0)+#define HANDLE_HIGH_MASK GENMASK_ULL(63, 32)+#define HANDLE_LOW(x) (u32)(FIELD_GET(HANDLE_LOW_MASK, (x)))+#define HANDLE_HIGH(x) (u32)(FIELD_GET(HANDLE_HIGH_MASK, (x)))++#define PACK_HANDLE(l, h) \+(FIELD_PREP(HANDLE_LOW_MASK,(l))|FIELD_PREP(HANDLE_HIGH_MASK,(h)))+/*+*Aglobally-uniqueIDassignedbythehypervisorforaregion+*ofmemorybeingsentbetweenVMs.+*/+u64handle;+/*+*Animplementationdefinedvalueassociatedwiththereceiverandthe+*memoryregion.+*/+u64tag;+u32reserved_1;+/*+*Thenumberof`ffa_mem_region_attributes`entriesincludedinthis+*transaction.+*/+u32ep_count;+/*+*Anarrayofendpointmemoryaccessdescriptors.+*Eachonespecifiesamemoryregionoffset,anendpointandthe+*attributeswithwhichthismemoryregionshouldbemappedinthat+*endpoint'spagetable.+*/+structffa_mem_region_attributesep_mem_access[];+};++#define COMPOSITE_OFFSET(x) \+(offsetof(structffa_mem_region,ep_mem_access[x]))+#define CONSTITUENTS_OFFSET(x) \+(offsetof(structffa_composite_mem_region,constituents[x]))+#define COMPOSITE_CONSTITUENTS_OFFSET(x, y) \+(COMPOSITE_OFFSET(x)+CONSTITUENTS_OFFSET(y))++structffa_mem_ops_args{+booluse_txbuf;+u32nattrs;+u32flags;+u64tag;+u64g_handle;+structscatterlist*sg;+structffa_mem_region_attributes*attrs;+};+structffa_dev_ops{u32(*api_version_get)(void);int(*partition_info_get)(constchar*uuid_str,
From: Rob Herring <robh@kernel.org> Date: 2021-03-05 20:40:34
On Fri, Feb 12, 2021 at 03:46:08PM +0000, Sudeep Holla wrote:
Since the FF-A v1.0 specification doesn't list the UUID of all the
partitions in the discovery API, we need to specify the UUID of the
partitions that need to be accessed by drivers within the kernel.
This binding to provide the list of partitions that kernel drivers
may need to access.
Signed-off-by: Sudeep Holla <redacted>
---
.../devicetree/bindings/arm/arm,ffa.yaml | 58 +++++++++++++++++++
1 file changed, 58 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/arm,ffa.yaml
Hi Rob,
Sorry to send the same version again just to keep the driver review progress.
I am still exploring on how to add "format: uuid" support in the dt-schemas.
I am seeing errors as format is used in some of the audio/video DT bindings.
I get errors for all those files, may be I need to use $format, initial
trial to do that also failed.
Other bindings shouldn't affect you. The meta-schema and maybe the
fixups are probably the issue. It's something I need to fix.
Regarding other comment, I had replied earlier[1] as why we need to keep
separate DT nodes for each partitions.
That's fine. It's the other users like TF-A that I'm now more concerned
about...
@@ -0,0 +1,58 @@+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)+%YAML1.2+---+$id:http://devicetree.org/schemas/arm/arm,ffa.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:Arm Firmware Framework for Arm v8-A (in-kernel users)++maintainers:+-Sudeep Holla <sudeep.holla@arm.com>++description:|+Firmware frameworks implementing partition according to the FF-A+specification defined by ARM document number ARM DEN 0077A ("Arm Firmware+Framework for Arm v8-A") [0], providing services to be used by other+partitions.++[0]https://developer.arm.com/docs/den0077/latest++properties:+$nodename:+const:ffa++compatible:+oneOf:+-const:arm,ffa-1.0++patternProperties:+"^ffa_partition[0-9]+$":
'^ffa-partition-[0-9a-f]+$'
+ type: object
+ description: One or more child nodes, each describing an FFA partition.
+ properties:
+ $nodename:
+ const: ffa_partition
+
+ compatible:
+ oneOf:
Hi Jens,
On Fri, Feb 12, 2021 at 03:46:07PM +0000, Sudeep Holla wrote:
Hi all,
This is very basic implementation for in-kernel support for Arm FF-A
specification.
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 secure partition. This is currently tested with OPTEE(with changes
to OPTEE driver adding FFA as transport)
Since you reviewed the last version, it would be helpful if you provide
Reviewed-by or Tested-by if you happy with this version. I would like to
get this initial version merged for v5.13
--
Regards,
Sudeep
On Fri, Feb 12, 2021 at 03:46:09PM +0000, Sudeep Holla wrote:
quoted hunk
SMCCC v1.2 allows x8-x17 to be used as parameter registers and x4—x17
to be used as result registers in SMC64/HVC64. Arm Firmware Framework
for Armv8-A specification makes use of x0-x7 as parameter and result
registers.
Current SMCCC interface in the kernel just use x0-x7 as parameter and
x0-x3 as result registers. Let us add new interface to support x0-x7
as parameter and result registers. This can be extended to include
x8-x17 when there are users for the same.
Signed-off-by: Sudeep Holla <redacted>
---
arch/arm64/kernel/asm-offsets.c | 4 +++
arch/arm64/kernel/smccc-call.S | 22 +++++++++++++++
include/linux/arm-smccc.h | 50 +++++++++++++++++++++++++++++++++
3 files changed, 76 insertions(+)
On Fri, Feb 12, 2021 at 4:46 PM Sudeep Holla [off-list ref] wrote:
Parse the FFA nodes from the device-tree and register all the partitions
whose services will be used in the kernel.
In order to also enable in-kernel users of FFA interface, let us add
simple set of operations for such devices.
The in-kernel users are registered without the character device interface.
Signed-off-by: Sudeep Holla <redacted>
---
drivers/firmware/arm_ffa/common.h | 2 +
drivers/firmware/arm_ffa/driver.c | 188 ++++++++++++++++++++++++++++++
include/linux/arm_ffa.h | 38 +++++-
3 files changed, 227 insertions(+), 1 deletion(-)
On Fri, Feb 12, 2021 at 4:46 PM Sudeep Holla [off-list ref] wrote:
Most of the MEM_* APIs share the same parameters, so they can be
generalised. Currently only MEM_SHARE is implemented and the user space
interface for that is not added yet.
Signed-off-by: Sudeep Holla <redacted>
---
drivers/firmware/arm_ffa/driver.c | 184 ++++++++++++++++++++++++++++++
include/linux/arm_ffa.h | 150 ++++++++++++++++++++++++
2 files changed, 334 insertions(+)
+struct ffa_mem_region {
+ /* The ID of the VM/owner which originally sent the memory region */
+ u16 sender_id;
+#define FFA_MEM_NORMAL BIT(5)
+#define FFA_MEM_DEVICE BIT(4)
+
+#define FFA_MEM_WRITE_BACK (3 << 2)
+#define FFA_MEM_NON_CACHEABLE (1 << 2)
+
+#define FFA_DEV_nGnRnE (0 << 2)
+#define FFA_DEV_nGnRE (1 << 2)
+#define FFA_DEV_nGRE (2 << 2)
+#define FFA_DEV_GRE (3 << 2)
+
+#define FFA_MEM_NON_SHAREABLE (0)
+#define FFA_MEM_OUTER_SHAREABLE (2)
+#define FFA_MEM_INNER_SHAREABLE (3)
+ u8 attributes;
+ u8 reserved_0;
+/*
+ * Clear memory region contents after unmapping it from the sender and
+ * before mapping it for any receiver.
+ */
+#define FFA_MEM_CLEAR BIT(0)
+/*
+ * Whether the hypervisor may time slice the memory sharing or retrieval
+ * operation.
+ */
+#define FFA_TIME_SLICE_ENABLE BIT(1)
+
+/*
+ * Whether the hypervisor should clear the memory region before the receiver
+ * relinquishes it or is aborted.
+ */
+#define FFA_MEM_CLEAR_BEFORE_RELINQUISH BIT(0)
I believe this should be clear before retrieval.
Thanks,
Jens
Hi Sudeep,
On Tue, Mar 16, 2021 at 3:34 PM Sudeep Holla [off-list ref] wrote:
Hi Jens,
On Fri, Feb 12, 2021 at 03:46:07PM +0000, Sudeep Holla wrote:
quoted
Hi all,
This is very basic implementation for in-kernel support for Arm FF-A
specification.
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 secure partition. This is currently tested with OPTEE(with changes
to OPTEE driver adding FFA as transport)
Since you reviewed the last version, it would be helpful if you provide
Reviewed-by or Tested-by if you happy with this version. I would like to
get this initial version merged for v5.13
I've tested this in a few of my setups and everything looks over all
fine, so please apply:
Tested-by: Jens Wiklander <redacted>
I'm also double checking the details of the patches for some further
feedback. Stay tuned.
Thanks,
Jens
On Fri, Feb 12, 2021 at 4:46 PM Sudeep Holla [off-list ref] wrote:
There are requests to keep the transport separate in order to allow
other possible transports like virtio. So let us keep the SMCCC transport
specific routines abstracted.
It is kept simple for now. Once we add another transport, we can develop
better abstraction.
Signed-off-by: Sudeep Holla <redacted>
---
drivers/firmware/arm_ffa/Kconfig | 5 +++
drivers/firmware/arm_ffa/Makefile | 3 +-
drivers/firmware/arm_ffa/common.h | 4 +++
drivers/firmware/arm_ffa/smccc.c | 54 +++++++++++++++++++++++++++++++
4 files changed, 65 insertions(+), 1 deletion(-)
create mode 100644 drivers/firmware/arm_ffa/smccc.c
On Fri, Feb 12, 2021 at 03:46:11PM +0000, Sudeep Holla wrote:
quoted hunk
This just add a basic driver that sets up the transport(e.g. SMCCC),
checks the FFA version implemented, get the partition ID for self and
sets up the Tx/Rx buffers for communication.
Signed-off-by: Sudeep Holla <redacted>
---
drivers/firmware/arm_ffa/Makefile | 3 +-
drivers/firmware/arm_ffa/bus.c | 14 +-
drivers/firmware/arm_ffa/common.h | 26 +++
drivers/firmware/arm_ffa/driver.c | 297 ++++++++++++++++++++++++++++++
4 files changed, 329 insertions(+), 11 deletions(-)
create mode 100644 drivers/firmware/arm_ffa/common.h
create mode 100644 drivers/firmware/arm_ffa/driver.c
On Thu, Mar 18, 2021 at 3:09 PM Jens Wiklander
[off-list ref] wrote:
Hi Sudeep,
On Tue, Mar 16, 2021 at 3:34 PM Sudeep Holla [off-list ref] wrote:
quoted
Hi Jens,
On Fri, Feb 12, 2021 at 03:46:07PM +0000, Sudeep Holla wrote:
quoted
Hi all,
This is very basic implementation for in-kernel support for Arm FF-A
specification.
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 secure partition. This is currently tested with OPTEE(with changes
to OPTEE driver adding FFA as transport)
Since you reviewed the last version, it would be helpful if you provide
Reviewed-by or Tested-by if you happy with this version. I would like to
get this initial version merged for v5.13
I've tested this in a few of my setups and everything looks over all
fine, so please apply:
Tested-by: Jens Wiklander <redacted>
I'm also double checking the details of the patches for some further
feedback. Stay tuned.
I'm done reviewing this patchset. I had a comment about a TODO in
"arm64: smccc: Add support for SMCCCv1.2 input/output registers", I
suppose it isn't very urgent with a 32-bit implementation.
Cheers,
Jens
Hi Jens,
On Thu, Mar 18, 2021 at 03:09:46PM +0100, Jens Wiklander wrote:
Hi Sudeep,
On Tue, Mar 16, 2021 at 3:34 PM Sudeep Holla [off-list ref] wrote:
quoted
Hi Jens,
On Fri, Feb 12, 2021 at 03:46:07PM +0000, Sudeep Holla wrote:
quoted
Hi all,
This is very basic implementation for in-kernel support for Arm FF-A
specification.
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 secure partition. This is currently tested with OPTEE(with changes
to OPTEE driver adding FFA as transport)
Since you reviewed the last version, it would be helpful if you provide
Reviewed-by or Tested-by if you happy with this version. I would like to
get this initial version merged for v5.13
I've tested this in a few of my setups and everything looks over all
fine, so please apply:
Tested-by: Jens Wiklander <redacted>
I'm also double checking the details of the patches for some further
feedback. Stay tuned.
Thanks a lot, much appreciated !
--
Regards,
Sudeep
On Fri, Mar 19, 2021 at 08:56:47AM +0100, Jens Wiklander wrote:
On Thu, Mar 18, 2021 at 3:09 PM Jens Wiklander
[off-list ref] wrote:
quoted
Hi Sudeep,
On Tue, Mar 16, 2021 at 3:34 PM Sudeep Holla [off-list ref] wrote:
quoted
Hi Jens,
On Fri, Feb 12, 2021 at 03:46:07PM +0000, Sudeep Holla wrote:
quoted
Hi all,
This is very basic implementation for in-kernel support for Arm FF-A
specification.
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 secure partition. This is currently tested with OPTEE(with changes
to OPTEE driver adding FFA as transport)
Since you reviewed the last version, it would be helpful if you provide
Reviewed-by or Tested-by if you happy with this version. I would like to
get this initial version merged for v5.13
I've tested this in a few of my setups and everything looks over all
fine, so please apply:
Tested-by: Jens Wiklander <redacted>
I'm also double checking the details of the patches for some further
feedback. Stay tuned.
I'm done reviewing this patchset. I had a comment about a TODO in
"arm64: smccc: Add support for SMCCCv1.2 input/output registers", I
suppose it isn't very urgent with a 32-bit implementation.
Thanks again, I will reply to that seperately. But yes, it is not
urgent as of now.
--
Regards,
Sudeep
On Fri, Mar 19, 2021 at 08:25:23AM +0100, Jens Wiklander wrote:
On Fri, Feb 12, 2021 at 03:46:11PM +0000, Sudeep Holla wrote:
quoted
This just add a basic driver that sets up the transport(e.g. SMCCC),
checks the FFA version implemented, get the partition ID for self and
sets up the Tx/Rx buffers for communication.
Signed-off-by: Sudeep Holla <redacted>
---
drivers/firmware/arm_ffa/Makefile | 3 +-
drivers/firmware/arm_ffa/bus.c | 14 +-
drivers/firmware/arm_ffa/common.h | 26 +++
drivers/firmware/arm_ffa/driver.c | 297 ++++++++++++++++++++++++++++++
4 files changed, 329 insertions(+), 11 deletions(-)
create mode 100644 drivers/firmware/arm_ffa/common.h
create mode 100644 drivers/firmware/arm_ffa/driver.c
On Wed, Mar 17, 2021 at 08:17:59AM +0100, Jens Wiklander wrote:
On Fri, Feb 12, 2021 at 03:46:09PM +0000, Sudeep Holla wrote:
quoted
SMCCC v1.2 allows x8-x17 to be used as parameter registers and x4—x17
to be used as result registers in SMC64/HVC64. Arm Firmware Framework
for Armv8-A specification makes use of x0-x7 as parameter and result
registers.
Current SMCCC interface in the kernel just use x0-x7 as parameter and
x0-x3 as result registers. Let us add new interface to support x0-x7
as parameter and result registers. This can be extended to include
x8-x17 when there are users for the same.
Signed-off-by: Sudeep Holla <redacted>
---
arch/arm64/kernel/asm-offsets.c | 4 +++
arch/arm64/kernel/smccc-call.S | 22 +++++++++++++++
include/linux/arm-smccc.h | 50 +++++++++++++++++++++++++++++++++
3 files changed, 76 insertions(+)
@@ -155,6 +155,56 @@ struct arm_smccc_res {unsignedlonga3;};+#ifdef CONFIG_ARM64+/* TODO Need to implement for ARM too */
It would be nice to have this TODO resolved.
Agreed, but I don't have a complete stack to test this and bit nervous to push
untested code out or even merge it. We can push/get that merged when there
is need for it. It is definitely in my TODO list.
Thanks for all the review and testing. Sorry for the delay in response.
I was off until yesterday.
--
Regards,
Sudeep