On 2021/1/13 下午11:52, Stefan Hajnoczi wrote:
On Wed, Jan 13, 2021 at 10:38:29AM +0800, Jason Wang wrote:
On 2021/1/8 上午1:53, Stefan Hajnoczi wrote:
On Thu, Jan 07, 2021 at 11:30:47AM +0800, Jason Wang wrote:
On 2021/1/6 下午11:05, Stefan Hajnoczi wrote:
On Wed, Jan 06, 2021 at 01:21:43PM +0800, Jason Wang wrote:
On 2021/1/5 下午6:25, Stefan Hajnoczi wrote:
On Tue, Jan 05, 2021 at 11:53:01AM +0800, Jason Wang wrote:
On 2021/1/5 上午8:02, Elena Afanasova wrote:
On Mon, 2021-01-04 at 13:34 +0800, Jason Wang wrote:
On 2021/1/4 上午4:32, Elena Afanasova wrote:
On Thu, 2020-12-31 at 11:45 +0800, Jason Wang wrote:
On 2020/12/29 下午6:02, Elena Afanasova wrote:
2. If separate userspace threads process the virtqueues, then set up the
virtio-pci capabilities so the virtqueues have separate notification
registers:
https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x1-1150004
Right. But this works only when PCI transport is used and queue index could
be deduced from the register address (separated doorbell).
If we use MMIO or sharing the doorbell registers among all the virtqueues
(multiplexer is zero in the above case) , it can't work without datamatch.
True. Can you think of an application that needs to dispatch a shared
doorbell register to several threads?
I think it depends on semantic of doorbell register. I guess one example
is the virito-mmio multiqueue device.
If this is a case that real-world applications need then we should
tackle it. This is where eBPF would be appropriate. I guess the
interface would be something like:
/*
* A custom demultiplexer function that returns the index of the <wfd,
* rfd> pair to use or -1 to produce a KVM_EXIT_IOREGION_FAILURE that
* userspace must handle.
*/
int demux(const struct ioregionfd_cmd *cmd);
Userspace can install an eBPF demux function as well as an array of
<wfd, rfd> fd pairs. The demux function gets to look at the cmd in order
to decide which fd pair it is sent to.
This is how I think eBPF datamatch could work. It's not as general as in
our original discussion where we also talked about custom protocols
(instead of struct ioregionfd_cmd/struct ioregionfd_resp).
Actually they are not conflict. We can make it a eBPF ioregion, then
it's the eBPF program that can decide:
1) whether or not it need to do datamatch
2) how many file descriptors it want to use (store the fd in a map)
3) how will the protocol looks like
But as discussed it could be an add-on on top of the hard logic of
ioregion since there could be case that eBPF may not be allowed not not
supported. So adding simple datamatch support as a start might be a good
choice.
Thanks
Stefan
