On Tue, Oct 20, 2020 at 10:52:08AM +0000, Fran??ois Ozog via Stratos-dev wrote:
To fuel discussion on inter-VM communication over virtio... I think virtio end-points may be in normal world, secure world (Secure Media Path?) or "real time" world (RTOS on cortex-M). I believe the FF-A backend for the topic was also a key element of the discussion (Is it correct Azzedine?)
FYI, I'm currently trying to run zephyr in a guest vm on Xen/qemu(arm64) and now confirmed that a simple application, samples/hello_world, successfully ran though we need a couple of tweaks :)
qemu-arm64 -> TF-A -> U-Boot -> grub -> Xen(4.15+) -> Debian testing -> U-Boot(!, domU) -> Zephyr/hello_world
I started this task just for myself to learn more about Xen, but if people are interested in it (for demo, evaluation or testing), I'm keen to continue to work on this.
Thanks, -Takahiro Akashi
Cheers
FF ---------- Forwarded message --------- From: Joao Alves via Hafnium hafnium@lists.trustedfirmware.org Date: Tue, 20 Oct 2020 at 12:18 Subject: [Hafnium] FFA Memory Management Interfaces To: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org, Andrew Walbran qwandor@google.com
Hello All,
We have been working on enabling the use memory management interfaces between SWd and NWd, on Hafnium as SPMC. We identified a few points that would benefit from a general discussion/clarification through the Mailing List for this work to progress on time for the first release.
The whole memory has been mapped to a VM representative of the NWd FFA endpoints (in the code can be found as a global variable called 'other_world_vm') in this patch< https://review.trustedfirmware.org/c/hafnium/hafnium/+/6008%3E. All the memory is configured as RW memory, to be permissive enough to ease the validation of the sender's original permissions vs the requested sharing permissions. This approach seems valid given the following assumptions: the 'other_world_vm' is never scheduled, which means that there is no risk of memory leakage; the hypervisor should do the necessary validation of the permissions that a given NWd FFA endpoint has on a given memory region, before forwarding the handling of the operation to the SPMC.
The first point to bring to discussion is regarding the RW configuration. Is this really the best configuration we would expect for memory to be shared from NWd to the SWd? Or is this excluding any use-case we are not aware of (e.g. at this point we are restricting instruction permissions to NX)?
Whilst testing the memory management interfaces, I noticed that if the instruction access on the memory region descriptor (in the spec has been described in section 5.12, and in the code defined as 'struct ffa_memory_region') is set as 'not specified' for the Lend and Donate operations, the receiver would acquire permission to execute the memory region. This is due to the implementation of the function 'ffa_memory_permissions_to_mode< https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n3...
<
https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n3...', which sets the memory mode to MM_MODE_X for case instruction access FFA_INSTRUCTION_ACCESS_NOT_SPECIFIED. My understanding is that in such case MM_MODE_X shouldn't be set. Please check this change< https://review.trustedfirmware.org/c/hafnium/hafnium/+/6008%3E. @Andrew Walbranmailto:qwandor@google.com, is the change I provided correct? Or is there a reason for the current implementation of 'ffa_memory_permissions_to_mode'?
I also noticed that after a memory reclaim, the sender/owner of a memory region acquires RW and X permissions, even if these were not part of the original permissions when sending the memory region. This is due to definition of the variable 'memory_to_attributes' in the function 'ffa_memory_reclaim< https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n2...
':
uint32_t memory_to_attributes = MM_MODE_R | MM_MODE_W | MM_MODE_X; Down the call stack, the value of this variable is used to update the variable 'to_mode' in function 'ffa_retrieve_check_transition< https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n6...'. The value of variable 'to_mode' is later passed to 'ffa_region_group_identity_map'< https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n1... to update the owner's memory mapping. My understanding is that the sender's memory mode should be reset to the mode it had prior to the original memory send operation, and that this is going to be a problem for memory management operations (even between between VMs and between SPs). I have seen this behavior on my set, however I would like to validate my analysis. @Andrew Walbranmailto:qwandor@google.com would you be able to provide any comments on this?
Please let me know if anyone has any comments/questions.
Best regards, João Alves
-- Hafnium mailing list Hafnium@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog -- Stratos-dev mailing list Stratos-dev@op-lists.linaro.org https://op-lists.linaro.org/mailman/listinfo/stratos-dev