Hi Viresh,
On 27 Apr 2026, at 12:40, Viresh Kumar viresh.kumar@linaro.org wrote:
Hi Bertrand,
On 23-04-26, 13:40, Bertrand Marquis wrote:
Hi Everyone,
I have a first PoC showing virtio-msg working with a loopback system between Linux kernel and Qemu.
The patches, build and run instructions can be found here:
https://github.com/bertrand-marquis/virtio-msg-spec/tree/linux-poc/v0/linux-...
This is very early stage but this shows a fully functional version with rng and block validated. I used ChatGPT help to fix issues and write part of the code (or big parts for Qemu) and this is far from upstreamable so do not share that.
I will share a v1 in the next weeks with FF-A support but i still have some timings and DMA issues to solve.
Any comment on this is more than welcome !!
I tried to go through the kernel patches and it was a lot (~14k lines of code). After a while, I parsed it using chatgpt :)
There are few basic question I have:
- As I understand, this is a completely new and parallel implementation (with
almost no similarity) with the one we already have (and sent as the first RFC). Is this interpretation correct ? I was hoping patches on top of the work already done in this area :(
I started from your patches but after some time the changes done where making it easier to start from scratch so i squashed my history to make things simpler. So yes probably not much remaining if anything from your patches
- I see a lot of complexity being added, like networking style bridge between
endpoints, etc. Why is this required ? What is it that the current design fails to address ? I am sure there must be reasons behind that, I am not sure what doesn't work right now. Sorry about that.
As said during the meeting, I encountered a lot of issues related to: - blocking in code that cannot sleep - dma handling issues - timings and concurrency during probe or runtime
So current design is trying to: - leave the transport out of the timing and concurrency complexity - have loopback really behaving as a bus from transport or bridge side - have ffa bus work in indirect and fifo cases which are introducing lots of defer work issues (I am trying to unify this right now to simplify a bit)
Code is huge but my focus right now is not having simple code but having it working and right now i still have issues to solve before i can be sure that i have all corner cases so that i can work on simplifying. This morning i just detected a new one where if fifo configure fails, current code was trying to unbind in a non sleepable context which was ending up in an error in the kernel because ffa driver was trying to flush possible request before accepting the unbind (I am redesigning that part in arm_ffa and ffa bus right now).
- I am sorry that I wasn't able to do any deep reviews of the code for now, the
code is really _big_ :)
I can definitely understand and i do not expect you to at this stage to go in any details.
If you can try to review something right now that would be the transport (ignore bus and bridge) as it is the part where i feel i am mostly stable and complete (tm).
For the rest i will try to reduce the code size a bit and simplify but honestly the whole asynchronous part is very challenging (just look at what i had to do to have dma working with loopback and the dma helper....)
Cheers Bertrand
Thanks.
-- viresh
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.