Hi
On Thu, Sep 1, 2016 at 12:19 PM Wei Wang <> 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
