On Thu, Jan 14, 2021 at 12:05:00PM +0800, Jason Wang wrote: > > 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. Good point. virtio-mmio really needs datamatch if virtqueues are handled by different threads. > > 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. Let's go further. Can you share pseudo-code for the eBPF program's function signature (inputs/outputs)? Stefan
Attachment:
signature.asc
Description: PGP signature
