From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753770AbbKXMjF (ORCPT ); Tue, 24 Nov 2015 07:39:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37818 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753398AbbKXMjA (ORCPT ); Tue, 24 Nov 2015 07:39:00 -0500 Message-ID: <1448368735.27648.110.camel@redhat.com> Subject: Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel From: Gerd Hoffmann To: Daniel Vetter Cc: Alex Williamson , "igvt-g@ml01.01.org" , "Li, Susie" , "White, Michael L" , "Dong, Eddie" , "intel-gfx@lists.freedesktop.org" , "Reddy, Raghuveer" , "Cowperthwaite, David J" , "linux-kernel@vger.kernel.org" , "xen-devel@lists.xen.org" , qemu-devel , "Zhou, Chao" , Paolo Bonzini , "Zhu, Libo" , "Wang, Hongbo" Date: Tue, 24 Nov 2015 13:38:55 +0100 In-Reply-To: <20151124111917.GO17050@phenom.ffwll.local> References: <53D215D3.50608@intel.com> <547FCAAD.2060406@intel.com> <54AF967B.3060503@intel.com> <5527CEC4.9080700@intel.com> <559B3E38.1080707@intel.com> <562F4311.9@intel.com> <1447870341.4697.92.camel@redhat.com> <1447963356.4697.184.camel@redhat.com> <20151124111917.GO17050@phenom.ffwll.local> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > > Yes, vGPU may have additional features, like a framebuffer area, that > > aren't present or optional for direct assignment. Obviously we support > > direct assignment of GPUs for some vendors already without this feature. > > For exposing framebuffers for spice/vnc I highly recommend against > anything that looks like a bar/fixed mmio range mapping. First this means > the kernel driver needs to internally fake remapping, which isn't fun. Sure. I don't think we should remap here. More below. > My recoomendation is to build the actual memory access for underlying > framebuffers on top of dma-buf, so that it can be vacuumed up by e.g. the > host gpu driver again for rendering. We want that too ;) Some more background: OpenGL support in qemu is still young and emerging, and we are actually building on dma-bufs here. There are a bunch of different ways how guest display output is handled. At the end of the day it boils down to only two fundamental cases though: (a) Where qemu doesn't need access to the guest framebuffer - qemu directly renders via opengl (works today with virtio-gpu and will be in the qemu 2.5 release) - qemu passed on the dma-buf to spice client for local display (experimental code exists). - qemu feeds the guest display into gpu-assisted video encoder to send a stream over the network (no code yet). (b) Where qemu must read the guest framebuffer. - qemu's builtin vnc server. - qemu writing screenshots to file. - (non-opengl legacy code paths for local display, will hopefully disappear long-term though ...) So, the question is how to support (b) best. Even with OpenGL support in qemu improving over time I don't expect this going away completely anytime soon. I think it makes sense to have a special vfio region for that. I don't think remapping makes sense there. It doesn't need to be "live", it doesn't need support high refresh rates. Placing a copy of the guest framebuffer there on request (and convert from tiled to linear while being at it) is perfectly fine. qemu has a adaptive update rate and will stop doing frequent update requests when the vnc client disconnects, so there will be nothing to do if nobody wants actually see the guest display. Possible alternative approach would be to import a dma-buf, then use glReadPixels(). I suspect when doing the copy in the kernel the driver could ask just the gpu to blit the guest framebuffer. Don't know gfx hardware good enough to be sure though, comments are welcome. cheers, Gerd From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1CsD-0003tI-Ey for qemu-devel@nongnu.org; Tue, 24 Nov 2015 07:39:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1Cs9-0007Zs-Do for qemu-devel@nongnu.org; Tue, 24 Nov 2015 07:39:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45057) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1Cs9-0007Zn-6Q for qemu-devel@nongnu.org; Tue, 24 Nov 2015 07:39:01 -0500 Message-ID: <1448368735.27648.110.camel@redhat.com> From: Gerd Hoffmann Date: Tue, 24 Nov 2015 13:38:55 +0100 In-Reply-To: <20151124111917.GO17050@phenom.ffwll.local> References: <53D215D3.50608@intel.com> <547FCAAD.2060406@intel.com> <54AF967B.3060503@intel.com> <5527CEC4.9080700@intel.com> <559B3E38.1080707@intel.com> <562F4311.9@intel.com> <1447870341.4697.92.camel@redhat.com> <1447963356.4697.184.camel@redhat.com> <20151124111917.GO17050@phenom.ffwll.local> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Daniel Vetter Cc: "igvt-g@ml01.01.org" , qemu-devel , "Reddy, Raghuveer" , "White, Michael L" , "Cowperthwaite, David J" , "intel-gfx@lists.freedesktop.org" , "Li, Susie" , "Dong, Eddie" , "linux-kernel@vger.kernel.org" , "xen-devel@lists.xen.org" , Alex Williamson , "Zhou, Chao" , Paolo Bonzini , "Zhu, Libo" , "Wang, Hongbo" Hi, > > Yes, vGPU may have additional features, like a framebuffer area, that > > aren't present or optional for direct assignment. Obviously we support > > direct assignment of GPUs for some vendors already without this feature. > > For exposing framebuffers for spice/vnc I highly recommend against > anything that looks like a bar/fixed mmio range mapping. First this means > the kernel driver needs to internally fake remapping, which isn't fun. Sure. I don't think we should remap here. More below. > My recoomendation is to build the actual memory access for underlying > framebuffers on top of dma-buf, so that it can be vacuumed up by e.g. the > host gpu driver again for rendering. We want that too ;) Some more background: OpenGL support in qemu is still young and emerging, and we are actually building on dma-bufs here. There are a bunch of different ways how guest display output is handled. At the end of the day it boils down to only two fundamental cases though: (a) Where qemu doesn't need access to the guest framebuffer - qemu directly renders via opengl (works today with virtio-gpu and will be in the qemu 2.5 release) - qemu passed on the dma-buf to spice client for local display (experimental code exists). - qemu feeds the guest display into gpu-assisted video encoder to send a stream over the network (no code yet). (b) Where qemu must read the guest framebuffer. - qemu's builtin vnc server. - qemu writing screenshots to file. - (non-opengl legacy code paths for local display, will hopefully disappear long-term though ...) So, the question is how to support (b) best. Even with OpenGL support in qemu improving over time I don't expect this going away completely anytime soon. I think it makes sense to have a special vfio region for that. I don't think remapping makes sense there. It doesn't need to be "live", it doesn't need support high refresh rates. Placing a copy of the guest framebuffer there on request (and convert from tiled to linear while being at it) is perfectly fine. qemu has a adaptive update rate and will stop doing frequent update requests when the vnc client disconnects, so there will be nothing to do if nobody wants actually see the guest display. Possible alternative approach would be to import a dma-buf, then use glReadPixels(). I suspect when doing the copy in the kernel the driver could ask just the gpu to blit the guest framebuffer. Don't know gfx hardware good enough to be sure though, comments are welcome. cheers, Gerd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel Date: Tue, 24 Nov 2015 13:38:55 +0100 Message-ID: <1448368735.27648.110.camel@redhat.com> References: <53D215D3.50608@intel.com> <547FCAAD.2060406@intel.com> <54AF967B.3060503@intel.com> <5527CEC4.9080700@intel.com> <559B3E38.1080707@intel.com> <562F4311.9@intel.com> <1447870341.4697.92.camel@redhat.com> <1447963356.4697.184.camel@redhat.com> <20151124111917.GO17050@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by gabe.freedesktop.org (Postfix) with ESMTPS id 402226E8DD for ; Tue, 24 Nov 2015 04:39:01 -0800 (PST) In-Reply-To: <20151124111917.GO17050@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: "igvt-g@ml01.01.org" , qemu-devel , "Reddy, Raghuveer" , "White, Michael L" , "Cowperthwaite, David J" , "intel-gfx@lists.freedesktop.org" , "Li, Susie" , "Dong, Eddie" , "linux-kernel@vger.kernel.org" , "xen-devel@lists.xen.org" , "Zhou, Chao" , Paolo Bonzini , "Zhu, Libo" , "Wang, Hongbo" List-Id: intel-gfx@lists.freedesktop.org ICBIaSwKCj4gPiBZZXMsIHZHUFUgbWF5IGhhdmUgYWRkaXRpb25hbCBmZWF0dXJlcywgbGlrZSBh IGZyYW1lYnVmZmVyIGFyZWEsIHRoYXQKPiA+IGFyZW4ndCBwcmVzZW50IG9yIG9wdGlvbmFsIGZv ciBkaXJlY3QgYXNzaWdubWVudC4gIE9idmlvdXNseSB3ZSBzdXBwb3J0Cj4gPiBkaXJlY3QgYXNz aWdubWVudCBvZiBHUFVzIGZvciBzb21lIHZlbmRvcnMgYWxyZWFkeSB3aXRob3V0IHRoaXMgZmVh dHVyZS4KPiAKPiBGb3IgZXhwb3NpbmcgZnJhbWVidWZmZXJzIGZvciBzcGljZS92bmMgSSBoaWdo bHkgcmVjb21tZW5kIGFnYWluc3QKPiBhbnl0aGluZyB0aGF0IGxvb2tzIGxpa2UgYSBiYXIvZml4 ZWQgbW1pbyByYW5nZSBtYXBwaW5nLiBGaXJzdCB0aGlzIG1lYW5zCj4gdGhlIGtlcm5lbCBkcml2 ZXIgbmVlZHMgdG8gaW50ZXJuYWxseSBmYWtlIHJlbWFwcGluZywgd2hpY2ggaXNuJ3QgZnVuLgoK U3VyZS4gIEkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIHJlbWFwIGhlcmUuICBNb3JlIGJlbG93LgoK PiBNeSByZWNvb21lbmRhdGlvbiBpcyB0byBidWlsZCB0aGUgYWN0dWFsIG1lbW9yeSBhY2Nlc3Mg Zm9yIHVuZGVybHlpbmcKPiBmcmFtZWJ1ZmZlcnMgb24gdG9wIG9mIGRtYS1idWYsIHNvIHRoYXQg aXQgY2FuIGJlIHZhY3V1bWVkIHVwIGJ5IGUuZy4gdGhlCj4gaG9zdCBncHUgZHJpdmVyIGFnYWlu IGZvciByZW5kZXJpbmcuCgpXZSB3YW50IHRoYXQgdG9vIDspCgpTb21lIG1vcmUgYmFja2dyb3Vu ZDoKCk9wZW5HTCBzdXBwb3J0IGluIHFlbXUgaXMgc3RpbGwgeW91bmcgYW5kIGVtZXJnaW5nLCBh bmQgd2UgYXJlIGFjdHVhbGx5CmJ1aWxkaW5nIG9uIGRtYS1idWZzIGhlcmUuICBUaGVyZSBhcmUg YSBidW5jaCBvZiBkaWZmZXJlbnQgd2F5cyBob3cKZ3Vlc3QgZGlzcGxheSBvdXRwdXQgaXMgaGFu ZGxlZC4gIEF0IHRoZSBlbmQgb2YgdGhlIGRheSBpdCBib2lscyBkb3duIHRvCm9ubHkgdHdvIGZ1 bmRhbWVudGFsIGNhc2VzIHRob3VnaDoKCiAgKGEpIFdoZXJlIHFlbXUgZG9lc24ndCBuZWVkIGFj Y2VzcyB0byB0aGUgZ3Vlc3QgZnJhbWVidWZmZXIKICAgICAgLSBxZW11IGRpcmVjdGx5IHJlbmRl cnMgdmlhIG9wZW5nbCAod29ya3MgdG9kYXkgd2l0aCB2aXJ0aW8tZ3B1CiAgICAgICAgYW5kIHdp bGwgYmUgaW4gdGhlIHFlbXUgMi41IHJlbGVhc2UpCiAgICAgIC0gcWVtdSBwYXNzZWQgb24gdGhl IGRtYS1idWYgdG8gc3BpY2UgY2xpZW50IGZvciBsb2NhbCBkaXNwbGF5CiAgICAgICAgKGV4cGVy aW1lbnRhbCBjb2RlIGV4aXN0cykuCiAgICAgIC0gcWVtdSBmZWVkcyB0aGUgZ3Vlc3QgZGlzcGxh eSBpbnRvIGdwdS1hc3Npc3RlZCB2aWRlbyBlbmNvZGVyCiAgICAgICAgdG8gc2VuZCBhIHN0cmVh bSBvdmVyIHRoZSBuZXR3b3JrIChubyBjb2RlIHlldCkuCgogIChiKSBXaGVyZSBxZW11IG11c3Qg cmVhZCB0aGUgZ3Vlc3QgZnJhbWVidWZmZXIuCiAgICAgIC0gcWVtdSdzIGJ1aWx0aW4gdm5jIHNl cnZlci4KICAgICAgLSBxZW11IHdyaXRpbmcgc2NyZWVuc2hvdHMgdG8gZmlsZS4KICAgICAgLSAo bm9uLW9wZW5nbCBsZWdhY3kgY29kZSBwYXRocyBmb3IgbG9jYWwgZGlzcGxheSwgd2lsbAogICAg ICAgICBob3BlZnVsbHkgZGlzYXBwZWFyIGxvbmctdGVybSB0aG91Z2ggLi4uKQoKU28sIHRoZSBx dWVzdGlvbiBpcyBob3cgdG8gc3VwcG9ydCAoYikgYmVzdC4gIEV2ZW4gd2l0aCBPcGVuR0wgc3Vw cG9ydAppbiBxZW11IGltcHJvdmluZyBvdmVyIHRpbWUgSSBkb24ndCBleHBlY3QgdGhpcyBnb2lu ZyBhd2F5IGNvbXBsZXRlbHkKYW55dGltZSBzb29uLgoKSSB0aGluayBpdCBtYWtlcyBzZW5zZSB0 byBoYXZlIGEgc3BlY2lhbCB2ZmlvIHJlZ2lvbiBmb3IgdGhhdC4gIEkgZG9uJ3QKdGhpbmsgcmVt YXBwaW5nIG1ha2VzIHNlbnNlIHRoZXJlLiAgSXQgZG9lc24ndCBuZWVkIHRvIGJlICJsaXZlIiwg aXQKZG9lc24ndCBuZWVkIHN1cHBvcnQgaGlnaCByZWZyZXNoIHJhdGVzLiAgUGxhY2luZyBhIGNv cHkgb2YgdGhlIGd1ZXN0CmZyYW1lYnVmZmVyIHRoZXJlIG9uIHJlcXVlc3QgKGFuZCBjb252ZXJ0 IGZyb20gdGlsZWQgdG8gbGluZWFyIHdoaWxlCmJlaW5nIGF0IGl0KSBpcyBwZXJmZWN0bHkgZmlu ZS4gIHFlbXUgaGFzIGEgYWRhcHRpdmUgdXBkYXRlIHJhdGUgYW5kCndpbGwgc3RvcCBkb2luZyBm cmVxdWVudCB1cGRhdGUgcmVxdWVzdHMgd2hlbiB0aGUgdm5jIGNsaWVudApkaXNjb25uZWN0cywg c28gdGhlcmUgd2lsbCBiZSBub3RoaW5nIHRvIGRvIGlmIG5vYm9keSB3YW50cyBhY3R1YWxseSBz ZWUKdGhlIGd1ZXN0IGRpc3BsYXkuCgpQb3NzaWJsZSBhbHRlcm5hdGl2ZSBhcHByb2FjaCB3b3Vs ZCBiZSB0byBpbXBvcnQgYSBkbWEtYnVmLCB0aGVuIHVzZQpnbFJlYWRQaXhlbHMoKS4gIEkgc3Vz cGVjdCB3aGVuIGRvaW5nIHRoZSBjb3B5IGluIHRoZSBrZXJuZWwgdGhlIGRyaXZlcgpjb3VsZCBh c2sganVzdCB0aGUgZ3B1IHRvIGJsaXQgdGhlIGd1ZXN0IGZyYW1lYnVmZmVyLiAgRG9uJ3Qga25v dyBnZngKaGFyZHdhcmUgZ29vZCBlbm91Z2ggdG8gYmUgc3VyZSB0aG91Z2gsIGNvbW1lbnRzIGFy ZSB3ZWxjb21lLgoKY2hlZXJzLAogIEdlcmQKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpJbnRlbC1nZnggbWFpbGluZyBsaXN0CkludGVsLWdmeEBsaXN0 cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ludGVsLWdmeAo=