Re: [Qemu-devel] [PATCH] *** Vhost-pci RFC v2 ***

[Wei Wang <wei.w.wang@intel.com>]

On 08/31/2016 08:30 PM, Marc-André Lureau wrote:
> Hi
>
> On Sun, Jun 19, 2016 at 10:19 AM Wei Wang <wei.w.wang@intel.com 
> <mailto:wei.w.wang@intel.com>> wrote:
>
>     This RFC proposes a design of vhost-pci, which is a new virtio
>     device type.
>     The vhost-pci device is used for inter-VM communication.
>
>
> Before I send a more complete review of the spec, I have a few overall 
> questions:
>
Hi Marc-André, thanks for joining the reviewing process :)

> - this patch is for the virtio spec? Why not patch the spec directly 
> (https://tools.oasis-open.org/version-control/browse/wsvn/virtio/trunk/) 
> I expect several rfc iterations, so perhaps it's easier as plain text 
> file for now (as a qemu patch to doc/specs). btw, I would limit the 
> audience at qemu-devel for now.

Yes. A part of the patch is for the virtio spec. I will separate the 
patches (please see the next response).
I have the qemu-devel and virtio mailinglist kept here.

> - I think the virtio spec should limit itself to the hw device 
> description, and virtioq messages. Not the backend implementation (the 
> ipc details, client/server etc).

Agree. I will separate the device spec description from the protocol 
description. The device description will be made a virtio spec patch, 
and the protocol description will be made a qemu patch to doc/specs.

> - 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 :)

Best,
Wei