On Tue, Feb 12, 2019 at 11:02:19PM -0500, Michael S. Tsirkin wrote:
> On Tue, Feb 12, 2019 at 06:50:29PM -0800, Frank Yang wrote:
> >
> >
> > On Tue, Feb 12, 2019 at 11:06 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> >     On Tue, Feb 12, 2019 at 09:26:10AM -0800, Frank Yang wrote:
> >     > BTW, the other unique aspect is that the ping messages allow a _host_
> >     pointer
> >     > to serve as the lump of shared memory;
> >     > then there is no need to track buffers in the guest kernel and the device
> >     > implementation can perform specialize buffer space management.
> >     > Because it is also host pointer shared memory, it is also physically
> >     contiguous
> >     > and there is no scatterlist needed to process the traffic.
> >
> >     Yes at the moment virtio descriptors all pass addresses guest to host.
> >
> >     Ability to reverse that was part of the vhost-pci proposal a while ago.
> >     BTW that also at least originally had ability to tunnel
> >     multiple devices over a single connection.
> >
> >
> >
> > Can there be a similar proposal for virtio-pci without vhsot?
> >
> >     There was nothing wrong with the proposals I think, they
> >     just had to be polished a bit before making it into the spec.
> >     And that runneling was dropped but I think it can be brought back
> >     if desired, we just didn't see a use for it.
> >
> >
> > Thinking about it more, I think vhost-pci might be too much for us due to the
> > vhost requirement (sockets and IPC while we desire a highly process local
> > solution)
>
> I agree because the patches try to document a bunch of stuff.
> But I really just mean taking the host/guest interface
> part from there.

Tomorrow I'll try to write up a little bit more about the vhost pci
ideas.  The patches on list go deep into envisioned implementation
detail within qemu instead of the actual host/guest interface.
You should then be able to figure out they are relevant for you.

--
MST