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

[geoff@hostfission.com]

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, geoff@hostfission.com 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, geoff@hostfission.com 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