[vbox-dev] Shared memory driver

[Alizée Penel]

Hi Klaus,

2016-08-08 11:17 GMT+02:00 Klaus Espenlaub <klaus.espenlaub at oracle.com>:

> Hi Alizée,
>
> On 02.08.2016 16:35, Alizée Penel wrote:
>
>> Hi,
>>
>> I am working for Genymobile which produces Genymotion Android emulator
>> (https://www.genymotion.com/features/), based on VirtualBox.
>>
>> For performance needs, we have to implement a VirtualBox shared memory
>> driver between guests and the host. We will intent to develop a driver
>> comparable to the QEMU pipe, implemented by the Google team
>> (https://android.googlesource.com/platform/external/qemu/+/e
>> mu-master-dev/docs/ANDROID-QEMU-PIPE.TXT).
>>
>> We may need a little help from you.
>>
>> Would you be interested by this feature ? If we develop a such driver,
>> would you put it upstream ?
>>
>
> It is interesting, but in the end we'd prefer a generic (not Android
> specific) solution here, which helps improving the 2D/3D handling by any
> VM. The Android/QEMU pipe is pretty special, in the sense that it is usable
> for both graphics and generic other functionality.
>

Actually, what we need most is a high bandwidth and low latency channel
between the host and guests for our OpenGL stream. It seems we are on the
same wavelength for that.

What we have in mind is using pipes as endpoints. Given how we handle 2D/3D
rendering, we need endpoints to be accessible from the userlands (host and
guests). This is why this channel could be used for other functionalities
and not only for the display.

Our specific use case is Windows, MacOS and Linux for the host side and
Android for the guest side.


>
> Right now it's too early to decide if the solution would be worth
> upstreaming. As long as it doesn't have negative effects on existing code
> or guest coverage I hope that the quality of what you're doing is good
> enough to integrate it. We don't want to make anyone's life unnecessarily
> difficult, and having features in the 'official' VirtualBox release is
> normally in the best interest of all users.


Then, we will wait for your decision when we submit our patches but we are
aware if we want our device to be upstreamed, we will need to add the
missing components on guest side, in the guest additions for Linux, Windows
and Mac, obviously.


>
>
> As far went our researches in VirtualBox sources, it seems that HGSMI
>> interface is what we need. Am I wrong ?
>>
>
> HGSMI is a solution specific to the graphics device which works using
> shared memory, and is actively used there for 3D accel with the existing
> device emulation and drivers inside the VM.
>
> Of course you can use it for doing more than graphics, but it's pushing
> the software architecture a little. Using HGSMI is only possible if the VGA
> device is active.
>

Do you mind if we "extract" HGSMI from graphic devices in order to be also
usable for others devices ? Or do you have another idea about this matter ?


>
> Klaus
> _______________________________________________
> vbox-dev mailing list
> vbox-dev at virtualbox.org
> https://www.virtualbox.org/mailman/listinfo/vbox-dev
>


-- 
Alizée PENEL
Software Engineer
apenel at genymobile.com
www.genymobile.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20160811/448dff86/attachment.html>