On 27-04-26, 12:00, Bertrand Marquis wrote:
On 27 Apr 2026, at 13:34, Viresh Kumar viresh.kumar@linaro.org wrote: We can have a spin-lock implementation for that ? How does the current code solve that ? Some sort of blocking needs to be done if the caller expects the response in the same thread.
I hope that can be done with a simple change over the current code.
thing is you need to sleep to wait for an answer, using a spinlock means we block waiting for an answer from an other VM or qemu in the kernel, this is not possible.
Right.
In some cases (event sending) you can solve that using deferred work but in some others (block driver during probe) i had to solve it with more complex systems:
- config register caches
- dma pool and kind of retry answer with defer pool increase so that next try
would have enough space in the pool to continue without blocking
I believe that can be done with current design too ?
Definitely ok with that but right now as said i want to have something working in full to be able to:
- ensure the spec is implementable
- check if there are some spec enhancements possible to simplify implementation
That's okay.
Maybe lets start with the problems one by one, with exact use-case to see what we are lacking right now. I am still not able to see the full picture (in sense of the problems we have).
My goal right now is to have the following working in loopback and using FF-A between 2 VMs using qemu as vmm:
- entropy device
- block device
and be able to stress the system by creating a file from entropy output inside the disk.
Nice.
I discovered that having entropy working is not that complex but disk is a lot more hacky.
Main issues i encountered so far:
- init chicken and egg: - device or driver coming first
Not sure why that is an issue. The Linux driver model will probe only after the device is available.
- driver needing to exchange messages or use dma during probe
This is quite normal and must be supported. Not sure what prevents that currently. I have tested I2C, GPIO, Vsock so far and they do basic message exchange at probe.
- messages exchanged or DMA share creation during non sleepable context
- qemu/vmm memory handling - when do you unshare - how can you ensure a share is ready before first event avail
- all timeout and queuing issues - how to sleep waiting for an answer or waiting to be able to send - how to stack (events for example) or defer - who has to sleep and when - how to handle defered work when exiting, removing a device or VM
Right, these all look valid concerns and I don't see why this can't work with the current implementation. Maybe we need to fix a few things here and there.
Right now i already have several consequences i need to handle in the spec
- we must have a pool, sharing on demand does not work for disk
Isn't that a device specific issue ? Why is this a virtio-msg kernel or spec issue ?
- if we have a pool the sharer must say when to release, otherwise we have to reshare the pool content as the device has no idea that something is a pool
- we need some config caching in the transport,
I feel that may not be the right approach. The transport should provide the mechanism to make it work, sleep-able and non-sleep-able (busy loop). The driver can choose to do what it wants, but it may not be correct for the transport to manage that.
Though it may be better to get views on this at the time of upstreaming. Maintainers may have a say in that and may not agree with what I said :)
otherwise any config value request from interrupt context which has to sleep cannot be processed
But that can busy loop ?
- config generation strict as it is cannot easily be implemented without ending up in loops because generation is changing while you refresh or you have to refresh the whole config cache each time one value is modified
Having something working by something working by simplifying the scope was easy but having something working in a realistic case is far more complex. I managed to have something working fully between qemu and the kernel which is what i shared but with ffa between VMs is still only working reliably only in simple cases.
Hopefully we won't require the complex design with bridges etc here and the simple one can be modified to sort this all out in the end. Lets see how it goes.