On Fri, Dec 15, 2017 at 06:33:45PM +0800, Wei Wang wrote: > On 12/15/2017 02:04 AM, Stefan Hajnoczi wrote: > > On Thu, Dec 14, 2017 at 01:53:16PM +0800, Wei Wang wrote: > > > 3rd one: I'm not able to solve this one, as discussed, there are too many > > > differences and it's too complex. I prefer the direction of simply gating > > > the vhost-user protocol and deliver to the guest what it should see (just > > > what this patch series shows). You would need to solve this issue to show > > > this direction is simpler :) > > At the moment the main issue deciding what to do seems to be that we > > have no patches for the approach I've described. I'll begin working on > > a patch series. > > > Are you planning to implement the multiple masters and slaves? > Master-->QemuSlave1-->GuestSlave > Master<--QemuSlave2<--GuestSlave
Not sure if we are thinking of the same model. Here's what I have in
mind:
Master <-> QEMU virtio-vhost-user-slave <-> GuestSlave
The virtio-vhost-user-slave device implements a vhost-user slave on the
host side and a virtio device that acts as a vhost-user master to the
guest. This is a single virtio device that speaks the vhost-user
protocol, not a family of different devices.
("virtio-vhost-user-slave" is the name to prevent confusion with your
vhost-pci work.)
I think your idea of using virtio is good since it avoids duplicating
low-level PCI device initialization and queues, so I've decided to try
that.
I will send a draft device specification later today so you can review
it. I think the virtio PCI transport mapping that I'm documenting will
be useful whether we choose vhost-pci or virtio-vhost-user-slave.
Stefan
signature.asc
Description: PGP signature
