Re: [virtio-dev] Memory sharing device

[Frank Yang <lfy@google.com>]

On Fri, Feb 22, 2019 at 2:05 PM Michael S. Tsirkin <mst@redhat.com> wrote:

On Wed, Feb 13, 2019 at 11:15:12PM -0800, Frank Yang wrote:
> Revised the spec to clean up a straggling mention of callbacks, and added a
> concrete example of how it would be used for a video codec.
>
> Inlined here:

BTW I'd rather you started sending versioned RFC patches.
This thread's too large already.

Ok, I've started a new thread on virtio-comment that re-shuffles the github links I've sent over so far, and responds to your latest questions. Thanks Michael!

Â

> \subsection{Example Use Case}\label{sec:Device Types / Host Memory Device /
> Example Use Case}
>
> Suppose the guest wants to decode a compressed video buffer.
>
> \begin{enumerate}
>
> \item Guest creates an instance for the codec vendor id / device id / revision.

OK we'll need to see how do we come up with a way to avoid conflicts
here, e.g. if multiple vendors will use this device.

> \item Guest allocates into the PCI region via config virtqueue messages.

OK so who allocates memory out of the PCI region?
Is it the host or the guest?
E.g. does guest say "I want X bytes" and host would respond
"here they are, start at offset X"?

> \item Guest sends a message over the ping virtqueue for the host to back that
> memory.

And all of these will need to be maintained on the host right?
How many of these regions need to be supported?

>
> \item Host codec device implementation exposes codec library's buffer directly
> to guest.
>
> \item Guest: now that the memory is host backed, the guest mmap()'s and
> Â Â downloads the compressed video stream directly to the host buffer.
>
> \item Guest: After a packet of compressed video stream is downloaded to the
> Â Â buffer, another message, like a doorbell, is sent on the ping virtqueue to
> Â Â Â Â consume existing compressed data. The ping message's offset field is
> Â Â Â Â set to the proper offset into the shared-mem object.

BTW is this terminology e.g. "download", "ping message" standard somewhere?

> \item Host: The ping message arrives on the host and the offset is resolved to
> Â Â a physical address and then, if possible, the physical address to a host
> Â Â Â Â pointer. Since the memory is now backed, the host pointer is also
> Â Â Â Â resolved.
>
> \item Host: Codec implementation decodes the video and puts the decoded frames
> Â Â to either a host-side display library (thus with no further guest
> Â Â Â Â communication necessary), or puts the raw decompressed frame to a
> Â Â Â Â further offset in the host buffer that the guest knows about.
>
> \item Guest: Continue downloading video streams and hitting the doorbell, or
> Â Â optionally, wait until the host is done first. If scheduling is not that
> Â Â Â Â big of an impact, this can be done without even any further VM exit, by
> Â Â Â Â the host writing to an agreed memory location when decoding is done,
> Â Â Â Â then the guest uses a polling sleep(N) where N is the correctly tuned
> Â Â Â Â timeout such that only a few poll spins are necessary.
>
>
> \item Guest: Or, the host can send back on the event virtqueue \field{revents}
> Â Â and the guest can perform a blocking read() for it.
>
> \end{enumerate}
>
> The unique / interesting aspects of virtio-hostmem are demonstrated:
>
> \begin{enumerate}
>
> \item During instance creation the host was allowed to reject the request if
> Â Â the codec device did not exist on host.
>
> \item The host can expose a codec library buffer directly to the guest,
> allowing the guest to write into it with zero copy and the host to decompress
> again without copying.
>
> \item Large bidirectional transfers are possible with zero copy.

However just to make sure, sending small amounts of data
is slower since you get to do all the mmap dance.


> \item Large bidirectional transfers are possible without scatterlists, because
> Â Â the memory is always physically contiguous.

It might get fragmented though. I think it would be up to
host to try and make sure it's not too fragmented, right?


> \item It is not necessary to use socket datagrams or data streams to
> Â Â communicate the ping messages; they can be raw structs fresh off the
> Â Â Â Â virtqueue.

OK and ping messages are all fixed size?


> \item After decoding, the guest has the option but not the requirement to wait
> Â Â for the host round trip, allowing for async operation of the codec.
>
> \item The guest has the option but not the requirement to wait for the host
> Â Â round trip, allowing for async operation of the codec.
>
> \end{enumerate}

OK I still owe you that write-up about vhost pci. will try to complete
that early next week. But generally if I got it right that the host
allocates buffers then what you describe does seem to fit a bit better
with the vhost pci host/guest interface idea.

One question that was asked about vhost pci is whether it is in fact
necessary to share a device between multiple applications.
Or is it enough to just have one id per device?

Thanks!
--
MST