[Notes for xen summit 2018 design session] Graphic virtualization

[Notes for xen summit 2018 design session] Graphic virtualization

[Julien Grall]

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

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

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.

The proprietary software would use IOREQ server infrastructure to
emulate guest memory region used by the GPU and do the scheduling
decisions.


-- 
Julien Grall

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

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

[Artem Mygaiev]

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[Lars Kurth]

On 02/08/2018, 16:27, "Artem Mygaiev" <artem_mygaiev@epam.com> wrote:

    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?

The presentation and recording is at
https://www.slideshare.net/xen_com_mgr/design-and-implementation-of-automotive-xpdds18-virtualization-based-on-xen-sungmin-lee-samsung-electronics
https://www.youtube.com/watch?v=mBD8o9X32fA&index=14&list=PLYyw7IQjL-zFlQYbY9BgsLhxqp1Ui67W7
  
Lars


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

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

[Artem Mygaiev]

Hi Lars

On 02.08.18 18:29, Lars Kurth wrote:
> 
> 
> On 02/08/2018, 16:27, "Artem Mygaiev" <artem_mygaiev@epam.com> wrote:
> 
>      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?
> 
> The presentation and recording is at
> https://www.slideshare.net/xen_com_mgr/design-and-implementation-of-automotive-xpdds18-virtualization-based-on-xen-sungmin-lee-samsung-electronics
> https://www.youtube.com/watch?v=mBD8o9X32fA&index=14&list=PLYyw7IQjL-zFlQYbY9BgsLhxqp1Ui67W7
>    

Thanks for pointing to XDS materials. Unfortunately, there is no 
comparison with "native" GPU performance (non-virtualized)... I guess I 
need to ask Samsung folks for details.

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

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

[Julien Grall]

Hi Artem,

On 02/08/18 16:54, Artem Mygaiev wrote:
> On 02.08.18 18:29, Lars Kurth wrote:
>>
>>
>> On 02/08/2018, 16:27, "Artem Mygaiev" <artem_mygaiev@epam.com> wrote:
>>
>>      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?
>>
>> The presentation and recording is at
>> https://www.slideshare.net/xen_com_mgr/design-and-implementation-of-automotive-xpdds18-virtualization-based-on-xen-sungmin-lee-samsung-electronics 
>>
>> https://www.youtube.com/watch?v=mBD8o9X32fA&index=14&list=PLYyw7IQjL-zFlQYbY9BgsLhxqp1Ui67W7 
>>
> 
> Thanks for pointing to XDS materials. Unfortunately, there is no 
> comparison with "native" GPU performance (non-virtualized)... I guess I 
> need to ask Samsung folks for details.
They do compare with Dom0 (slides 20 and onwards). Dom0 has the direct 
access to the GPU, so this is very similar to native.

Did you expect other comparison?

Cheers,


-- 
Julien Grall

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

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

[Artem Mygaiev]

On 02.08.18 18:57, Julien Grall wrote:
> Hi Artem,
> 
> On 02/08/18 16:54, Artem Mygaiev wrote:
>> On 02.08.18 18:29, Lars Kurth wrote:
>>>
>>>
>>> On 02/08/2018, 16:27, "Artem Mygaiev" <artem_mygaiev@epam.com> wrote:
>>>
>>>      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?
>>>
>>> The presentation and recording is at
>>> https://www.slideshare.net/xen_com_mgr/design-and-implementation-of-automotive-xpdds18-virtualization-based-on-xen-sungmin-lee-samsung-electronics 
>>>
>>> https://www.youtube.com/watch?v=mBD8o9X32fA&index=14&list=PLYyw7IQjL-zFlQYbY9BgsLhxqp1Ui67W7 
>>>
>>
>> Thanks for pointing to XDS materials. Unfortunately, there is no 
>> comparison with "native" GPU performance (non-virtualized)... I guess 
>> I need to ask Samsung folks for details.
> They do compare with Dom0 (slides 20 and onwards). Dom0 has the direct 
> access to the GPU, so this is very similar to native.
> 
> Did you expect other comparison?

Yes, implementation of sharing may impact Dom0 performance. In this case 
it seems that native GL applications in Dom0 are also reside in SVDM 
somehow (slide 14). I am not saying it is necessary impacting, but it is 
always better to have non-virtualized environment as a reference.

Too bad I couldn't make it to XDS due to conflict with AGL/OSS events :(

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

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

[Stefano Stabellini]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3131 bytes --]

On Thu, 2 Aug 2018, Artem Mygaiev wrote:
> On 02.08.18 18:57, Julien Grall wrote:
> > Hi Artem,
> > 
> > On 02/08/18 16:54, Artem Mygaiev wrote:
> > > On 02.08.18 18:29, Lars Kurth wrote:
> > > > 
> > > > 
> > > > On 02/08/2018, 16:27, "Artem Mygaiev" <artem_mygaiev@epam.com> wrote:
> > > > 
> > > >      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?
> > > > 
> > > > The presentation and recording is at
> > > > https://www.slideshare.net/xen_com_mgr/design-and-implementation-of-automotive-xpdds18-virtualization-based-on-xen-sungmin-lee-samsung-electronics 
> > > > https://www.youtube.com/watch?v=mBD8o9X32fA&index=14&list=PLYyw7IQjL-zFlQYbY9BgsLhxqp1Ui67W7 
> > > 
> > > Thanks for pointing to XDS materials. Unfortunately, there is no
> > > comparison with "native" GPU performance (non-virtualized)... I guess I
> > > need to ask Samsung folks for details.
> > They do compare with Dom0 (slides 20 and onwards). Dom0 has the direct
> > access to the GPU, so this is very similar to native.
> > 
> > Did you expect other comparison?
> 
> Yes, implementation of sharing may impact Dom0 performance. In this case it
> seems that native GL applications in Dom0 are also reside in SVDM somehow
> (slide 14). I am not saying it is necessary impacting, but it is always better
> to have non-virtualized environment as a reference.
> 
> Too bad I couldn't make it to XDS due to conflict with AGL/OSS events :(

I took his business card, I'll try to make introductions.

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

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

[Julien Grall]

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?

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

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

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

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

Cheers,

-- 
Julien Grall

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

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

[Artem Mygaiev]

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

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

[Stefano Stabellini]

On Fri, 3 Aug 2018, Artem Mygaiev wrote:
> > 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...

Yes, there will be more discussions. We talked about the changes we
would need to the virtio specification (then, the virtio frontends and
backends) to make it possible to use them effectively in the future, and
with proper isolation, with Xen (making driver domains possible, etc). A
couple of ideas were proposed, but we don't have a comprehensive list
yet.

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