Hi On Thu, Sep 1, 2016 at 12:19 PM Wei Wang <wei.w.w...@intel.com> wrote:
> 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. > > Yes, but it uses "backend" freely without any definition and to name eventually different things. (at least "slave" is being defined as the consumer of virtq, but I think some people don't like to use that word). Have you thought about making the device not pci specific? I don't know much about mmio devices nor s/390, but if devices can hotplug their own memory (I believe mmio can), then it should be possible to define a device generic enough. - 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. > > > Great! > - 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. > > That's what I imagined. Do you have a use case for that? Given that it's in a VM (no caching issues?), how is it a problem to map the same memory multiple times? Is there a memory limit? - 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. > > I guess it would be a good idea to have this in the spec from the beginning, not as an afterthought > > - when do you expect to share a wip/rfc implementation? > > Probably in October (next month). I think it also depends on the > discussions here :) > thanks -- Marc-André Lureau
