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

[Artem Mygaiev <artem_mygaiev@xxxxxxxx>]

Hello Julien

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

>     - 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?

>     - 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

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