OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [virtio-dev] Memory sharing device

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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]