Hi Ayrton / Armelle,
I tried to investigate about how to make VIRTIO_MSG_EVENT_USED work without
indirect FFA messages.
- Firstly, I am still not sure if I fully understand why indirect messages can't
be implemented on Trustee side ? I know it was discussed a bit in the call,
but I don't remember any of it :(
- If we want to do polling of the virtqueues, then it needs to be done on the
driver side (vsock), I don't see how I can generalize it and do it from
virtio-msg-ffa layer. The driver needs to do something like this for the
virtqueue:
while (1) {
/* Try to get a buffer from the virtqueue */
buf = virtqueue_get_buf(vq, &len);
if (buf) {
// Handle the received buffer
break;
}
/* Avoid busy looping with a small delay */
cpu_relax();
}
- The other idea discussed on the call was about always queuing a direct message
for a FFA device (not virtio device) for EVENT_USED message. Once the trustee
side has an event to send, it can respond to this request.
I was thinking if this may block the CPU for ever with the SMC call, but I
don't think that is the case. The FFA layer makes the SMC call, checks its
return value and sleeps for a ms, and tries again. With this the CPU will
schedule other work as soon as it can. And looks like we support sending
multiple direct messages concurrently too, so while a thread is waiting for a
response to EVENT_USED message, we can keep sending other messages.
If we want to support this, will this be part of the spec ? Bertrand ?
- Any other ideas on how to get this solved ?
--
viresh
All,
You will soon receive an email with the RFC series in its current state.
This is a test run; a draft of RFC just for members of this list.
If you see anything in the cover letter or commit message that you wish
to change please let me know by Monday at 4pm US Eastern time.
If you wish to be added to the Signed-off-by list or just the CC list
please let me know by the same deadline. Please specify which. It would
be good to include someone from Google (even if only in the CC).
Changes to the actual patch content is out of scope for now.
On Tuesday I will explain more about the branching and PR strategy going
forward. For now I am sending the RFC from a branch not yet on the
Linaro github.
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
All,
Deadline for issues and PRs: Wednesday Feb 12
Discussion: Thursday Feb 13
RFC Target: Friday Feb 21
We want to publish the first draft of the virtio-msg changes to the
virtio spec list as an RFC. We want to make sure:
1) It describes what we are doing
2) Is complete enough for virtio knowledgeable people to understand
3) _We_ don't need big changes*
* Reviewers may ask for big changes and we need to be prepared for that.
But we need to have our thinking on the same page collectively as much
as possible.
The work-in-progress spec is here:
https://github.com/Linaro/virtio-msg-spec
The most recent rendered pdf is here:
https://github.com/Linaro/virtio-msg-spec/releases
In addition there is pull request #5 that adds most of the things we
spoke of in our Dublin sprint:
https://github.com/Linaro/virtio-msg-spec/pull/5
All changes are in the file transport-msg.tex
(There is one change to content.tex to include the new file)
Providing feedback:
Unlike the upstream spec, we can use github issues and github pull
requests to manage changes within this group. Then one of us (myself or
Bertrand most likely) will send to upstream virtio spec mailing list.
To provide your feedback please create an issue or a PR.
For small changes it is probibly easier to just create a PR with the
exact wording you want. You can bundle a number commits into one PR but
try to keep each commit to one topic or one section.
After the RFC most of the interaction will move to
virtio-comment(a)lists.linux.dev so please subscribe now.
See the upstream README for details:
https://github.com/oasis-tcs/virtio-spec/blob/master/README.md
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Partition info may return self partition as well (specially with newer
versions of FFA spec), skip adding it twice.
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
Rebased over: 9967e35eb1cbdb8d0c0bae3f54401d806700e6b6.1732255888.git.viresh.kumar(a)linaro.org
drivers/firmware/arm_ffa/driver.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 34d9a54b6a77..b824c7c024fd 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -1424,6 +1424,9 @@ static int ffa_setup_partitions(void)
xa_init(&drv_info->partition_info);
for (idx = 0, tpbuf = pbuf; idx < count; idx++, tpbuf++) {
+ if (drv_info->vm_id == tpbuf->id)
+ continue;
+
/* Note that if the UUID will be uuid_null, that will require
* ffa_bus_notifier() to find the UUID of this partition id
* with help of ffa_device_match_uuid(). FF-A v1.1 and above
--
2.31.1.272.g89b43f80a514
Hello,
This series proposes basic DT bindings for FFA devices, and sets up the of_node
and dma_configure() callback for the devices.
Viresh Kumar (3):
dt-bindings: firmware: Add bindings for ARM FFA
firmware: arm_ffa: Setup of_node for ffa devices
firmware: arm_ffa: Provide .dma_configure()
.../devicetree/bindings/firmware/arm,ffa.yaml | 75 +++++++++++++++++++
drivers/firmware/arm_ffa/bus.c | 39 ++++++++++
2 files changed, 114 insertions(+)
create mode 100644 Documentation/devicetree/bindings/firmware/arm,ffa.yaml
--
2.31.1.272.g89b43f80a514
Hello,
I would like send this upstream next week, any feedback would be welcome before
that.
Thanks.
Viresh Kumar (2):
dt-bindings: firmware: Add bindings for ARM FFA
firmware: arm_ffa: Setup of_node for ffa devices
.../devicetree/bindings/firmware/arm,ffa.yaml | 75 +++++++++++++++++++
drivers/firmware/arm_ffa/bus.c | 30 ++++++++
2 files changed, 105 insertions(+)
create mode 100644 Documentation/devicetree/bindings/firmware/arm,ffa.yaml
--
2.31.1.272.g89b43f80a514
Hi Guys,
Happy new Year everyone.
I am travelling this week so i will not participate to the meeting but i pushed some changes to the specification in Alex Github mirror.
Those are introducing the error message in virtio-msg and some attempt to define the first bus messages.
The push contains some TODOs for which i would need some answers or ideas so feel free to look and tell me.
Also i wrote down a pending request to get an INT back when a notification is sent in case it cannot be sent and we will need to discuss it as adding an answer to EVENT messages would make those message synchronous which might not be the right idea. In the Bus to Transport interface definition of the google document, I did include an int return code when a message is sent by the transport and this could be used to signal back an error easily where posting a generated message back could introduce more complexity. This is just some thinking on my side and happy to discuss this in 2 weeks or by mail before that.
Regards
Bertrand
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
