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

[geoff]

The windows driver source is now available also.

https://github.com/gnif/Porthole-Guest-Driver

I have also opted to rename the device to 'porthole', hopefully this 
name is
acceptable.

On 2019-10-30 09:53, address@hidden wrote:
> Just to follow this up, here is a sample client application for this 
> device
>
> https://gist.github.com/gnif/77e7fb54604b42a1a98ecb8bf3d2cf46
>
> -Geoff
>
> On 2019-10-30 01:31, address@hidden wrote:
> > Hi All,
> >
> > Over the past week, I have been working to come up with a solution to 
> > the
> > memory transfer performance issues that hinder the Looking Glass 
> > Project.
> >
> > Currently Looking Glass works by using the IVSHMEM shared memory 
> > device which
> > is fed by an application that captures the guest's video output. While 
> > this
> > works it is sub-optimal because we first have to perform a CPU copy of 
> > the
> > captured frame into shared RAM, and then back out again for display. 
> > Because
> > the destination buffers are allocated by closed proprietary code 
> > (DirectX, or
> > NVidia NvFBC) there is no way to have the frame placed directly into 
> > the
> > IVSHMEM shared ram.
> >
> > 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.
> >
> > This device and the windows driver have been designed in such a way 
> > that it's a
> > utility device for any project and/or application that could make use 
> > of it.
> > The PCI subsystem vendor and device ID are used to provide a means of 
> > device
> > identification in cases where multiple devices may be in use for 
> > differing
> > applications. This also allows one common driver to be used for any 
> > other
> > projects wishing to build on this device.
> >
> > My ultimate goal is to get this to a state where it could be accepted 
> > upstream
> > into Qemu at which point Looking Glass would be modified to use it 
> > instead of
> > the IVSHMEM device.
> >
> > My git repository with the new device can be found at:
> > https://github.com/gnif/qemu
> >
> > The new device is:
> > https://github.com/gnif/qemu/blob/master/hw/misc/introspection.c
> >
> > Looking Glass:
> > https://looking-glass.hostfission.com/
> >
> > The windows driver, while working, needs some cleanup before the 
> > source is
> > published. I intend to maintain both this device and the windows 
> > driver
> > including producing a signed Windows 10 driver if Redhat are unwilling 
> > or
> > unable.
> >
> > Kind Regards,
> > Geoffrey McRae
> >
> > HostFission
> > https://hostfission.com