Re: RFC: New device for zero-copy VM memory access

[geoff]

On 2019-11-04 21:26, Gerd Hoffmann wrote:
> Hi,
>
> > This new device, currently named `introspection` (which needs a more
> > suitable name, porthole perhaps?), provides a means of translating
> > guest physical addresses to host virtual addresses, and finally to the
> > host offsets in RAM for file-backed memory guests. It does this by
> > means of a simple protocol over a unix socket (chardev) which is
> > supplied the appropriate fd for the VM's system RAM. The guest (in
> > this case, Windows), when presented with the address of a userspace
> > buffer and size, will mlock the appropriate pages into RAM and pass
> > guest physical addresses to the virtual device.
>
> So, if I understand things correctly, the workflow looks like this:
>
>   (1) guest allocates buffers, using guest ram.
>   (2) guest uses these buffers as render target for the gpu
> (pci-assigned I guess?).
>   (3) guest passes guest physical address to qemu (via porthole 
> device).
>   (4) qemu translates gpa into file offset and passes offsets to
>       the client application.
>   (5) client application maps all guest ram, then uses the offsets from
>       qemu to find the buffers.  Then goes displaying these buffers I 
> guess.
>
> Correct?

Correct, however step 5 might be a proxy to copy the buffers into 
another
porthole device in a second VM allowing VM->VM transfers.

> Performance aside for now, is it an option for your use case to simply
> use both an emulated display device and the assigned gpu, then 
> configure
> screen mirroring inside the guest to get the guest display scanned out
> to the host?

Unfortunately no, NVidia and AMD devices do not support mirroring their
outputs to a separate GPU unless it's a professional-grade GPU such as a
Quadro or Firepro.

-Geoff

> cheers,
>   Gerd