Re: [Notes for xen summit 2018 design session] Graphic virtualization

[Artem Mygaiev <artem_mygaiev@epam.com>]

Hi Julien

On 03.08.18 12:37, Julien Grall wrote:
> On 08/02/2018 04:26 PM, Artem Mygaiev wrote:
>> Hello Julien
> 
> Hi Artem,
> 
> Thank you for the feedback!
>> On 02.08.18 12:56, Julien Grall wrote:
>>> Hi,
>>>
>>> Sorry for the late posting. The notes were taken by Stefano 
>>> Stabellini. Thank you.
>>>
>>> This has some clarifications requested from EPAM regarding PowerVR.
>>>
>>> The existing graphics solutions on Xen today are:
>>>     - PV DRM:
>>>          * Supports multiple displays per VM
>>>          * Based on Grant-tables.
>>>          * Improvement of Xen FB which is based on foreign mapping
>>>
>> Frontend driver will be part of LK starting 4.18
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/xen?h=v4.18-rc7 
>>
> That's a good news. Do you know the state of the backend?
> 

PV display backend is implemented as a userspace service and available 
on our GutHub, along with ones for PV sound BE and library for writing 
userspace backends (everything is GPLv2):

https://github.com/xen-troops/displ_be
https://github.com/xen-troops/snd_be
https://github.com/xen-troops/libxenbe

>>
>>
>>>     - Intel GVT: https://01.org/igvt-g
>>>          * Based on IOREQ server infrastructure
>>>          * Performance is 70% of direct assigned hardware
>>>
>>>     - NVIDIA:
>>>          * Much more virtualizable
>>>          * Provide mappable chunk of PCI BARs.
>>>          * Userspace component emulates PCI config space
>>>
>>> Current effort for graphic virtualization on Arm:
>>>     - Samsung: They have a PV OpenGL solution. This seems to be fast.
>>
>> This is interesting. Do you know if there is any open benchmark data?
> 
> Stefano introduced you with the Samsung speaker. Hopefully we will get 
> more details on the benchmark.

If I get some more details - I'll share :)

> Unfortunately, PV OpenGL is not available upstream at the moment. It was 
> not clear whether the backend and frontend would ever be upstreamed and 
> when.
> 
> However, the work looks quite similar to virgil 
> (https://virgil3d.github.io/). It is Graphic virtualization solution 
> based on virtio for the transport. I think it would be possible to 
> re-use it by just replacing the transport layer.
> 
> Another solution is to implement virtio on Xen (see the discussion on 
> the last community call).

Do we plan some follow-up discussion on this? I have missed the call due 
to travels last couple weeks so I may not have a full picture...

>>>     - EPAM:
>>>          * PV OpenGL was dismissed because of performance concern
>>>          * PV DRM for sharing display
>>>          * PowerVR native virtualization (see below)
>>>
>>> PoverVR virtualization:
>>>
>>> Recent PoverVR hardware provided some virtualization support. The
>>> solution is implemented in the firmware. A kernel module is used to talk
>>> to the firmware via shared memory. The toolstack only have to setup
>>> memory context for each VM.
>>>
>>>             ** Recent PoverVR HW has some virtualization support
>>>             ** Kernel module
>>>
>>> It was not clear whether an extra pair of frontend/backend was 
>>> required along with the PowerVR driver.
>>>
>>> @Action: EPAM, could you clarify it?
>>>
>>
>> No, there are no extra FE/BE drivers for GPU sharing in case of PowerVR.
>>
>>> Potential solution for upstream:
>>>     - PV OpenGL
>>>     - vGPU solution outside of the hypervisor (see below)
>>>
>>> vGPU solution outside of the hypervisor:
>>>
>>> A unikernel (or Dom0) based environment could be provided to run
>>> proprietary software. >
>>
>> One more option we we were discussing is "de-priviledged" or "native 
>> applications in Xen:
>> https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg01002.html 
>>
>> We are looking into unikernels, too.
>>
>>> The proprietary software would use IOREQ server infrastructure to
>>> emulate guest memory region used by the GPU and do the scheduling
>>> decisions.
>>>
>>
>> We also had an RFC for co-processors (including GPU) management some 
>> time ago:
>> https://lists.xenproject.org/archives/html/xen-devel/2016-10/msg01966.html 
>>
> If I remember the series, the code may require to trap access to guest 
> GPU access and manage to the GPU. There are a fair amount of chance that 
> GPU vendors will not want to have that under GPL. So this would have to 
> live outside of Xen.

Yes, and taht's why we are looking into de-privileged applications and 
unikernels - GPU code will have intimate knowledge of GPU internals 
which is vendor's protected IP.

> This is where the IOREQ infrastructure comes into place. It allows to 
> forward MMIO access to an external entity. This entity could be 
> proprietary.

I need to look into this... I am not sure we used it before

  -- BR, Artem

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel