Re: [virtio-dev] Memory sharing device

From: Frank Yang <lfy@google.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Roman Kiryanov <rkir@google.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	virtio-dev@lists.oasis-open.org,
	Greg Hartman <ghartman@google.com>
Subject: Re: [virtio-dev] Memory sharing device
Date: Tue, 12 Feb 2019 20:59:27 -0800	[thread overview]
Message-ID: <CAEkmjvVD7E_DcBkoucNSYs74T10K2qrJHAYbzCqUF=7C+B-4GQ@mail.gmail.com> (raw)
In-Reply-To: <20190212231458-mutt-send-email-mst@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 2418 bytes --]

On Tue, Feb 12, 2019 at 8:19 PM Michael S. Tsirkin <mst@redhat.com> wrote:

> 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.
>
> Ok, looking forward! It does seems like a lot of what you are pointing
out, and in the vhost pci, what is specified is not strictly dependent on
the qemu implementation. Hopefully we can make the minimal set of changes
to support our constraints.


> --
> MST
>

[-- Attachment #2: Type: text/html, Size: 3359 bytes --]