[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [Qemu-devel] [PATCH] *** Vhost-pci RFC v2 ***
On 08/31/2016 08:30 PM, Marc-André Lureau wrote:
- If it could be made not pci-specific, a better name for the device could be simply "driver": the driver of a virtio device. Or the "slave" in vhost-user terminology - consumer of virtq. I think you prefer to call it "backend" in general, but I find it more confusing.
Not really. A virtio device has it own driver (e.g. a virtio-net driver for a virtio-net device). A vhost-pci device plays the role of a backend (just like vhost_net, vhost_user) for a virtio device. If we use the "device/driver" naming convention, the vhost-pci device is part of the "device". But I actually prefer to use "frontend/backend" :) If we check the QEMU's doc/specs/vhost-user.txt, it also uses "backend" to describe.
- regarding the socket protocol, why not reuse vhost-user? it seems to me it supports most of what you need and more (like interrupt, migrations, protocol features, start/stop queues). Some of the extensions, like uuid, could be beneficial to vhost-user too.
Right. We recently changed the plan - trying to make it (the vhost-pci protocol) an extension of the vhost-user protocol.
- Why is it required or beneficial to support multiple "frontend" devices over the same "vhost-pci" device? It could simplify things if it was a single device. If necessary, that could also be interesting as a vhost-user extension.We call it "multiple backend functionalities" (e.g. vhost-pci-net, vhost-pci-scsi..). A vhost-pci driver contains multiple such backend functionalities, because in this way they can reuse (share) the same memory mapping. To be more precise, a vhost-pci device supplies the memory of a frontend VM, and all the backend functionalities need to access the same frontend VM memory, so we consolidate them into one vhost-pci driver to use one vhost-pci device.
- no interrupt support, I suppose you mainly looked at poll-based net devices
Yes. But I think it's also possible to add the interrupt support. For example, we can use ioeventfd (or hypercall) to inject interrupts to the fontend VM after transmitting packets.
- when do you expect to share a wip/rfc implementation?
Probably in October (next month). I think it also depends on the discussions here :)