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.
Hi everyone,
I hope all interested parties are part of the previously created list.
Based on the discussions we had previously, where I was struggling to find a
setup where I can test virtio-msg with FFA (or something more realistic than
hacked-up MMIO), I decided to go ahead and make use of Bertrand's Xen patches
with Linux based host and guest VMs.
I now have a working setup with Bertrand's Xen patches, where we can do FFA I
was able to reuse my earlier setup (where we tested I2C with MMIO traps) based
virtio communication guest and host kernels. I have created another page [1]
(similar to previous one) for curious ones to replicate it.
This would work just fine for Vsock as well, which I tested earlier with the
backend from vhost-device crate.
--
viresh
[1] https://linaro.atlassian.net/wiki/spaces/HVAC/pages/29657792513/2024-11+ker…
