From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752739AbbKXLuM (ORCPT ); Tue, 24 Nov 2015 06:50:12 -0500 Received: from mail.fireflyinternet.com ([87.106.93.118]:56206 "EHLO fireflyinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752515AbbKXLuK (ORCPT ); Tue, 24 Nov 2015 06:50:10 -0500 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Date: Tue, 24 Nov 2015 11:49:39 +0000 From: Chris Wilson To: Alex Williamson , "Tian, Kevin" , "igvt-g@ml01.01.org" , "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" , qemu-devel , "Zhou, Chao" , Paolo Bonzini , "Zhu, Libo" , "Wang, Hongbo" Subject: Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel Message-ID: <20151124114939.GI22980@nuc-i3427.alporthouse.com> Mail-Followup-To: Chris Wilson , Alex Williamson , "Tian, Kevin" , "igvt-g@ml01.01.org" , "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" , qemu-devel , "Zhou, Chao" , Paolo Bonzini , "Zhu, Libo" , "Wang, Hongbo" 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=us-ascii Content-Disposition: inline In-Reply-To: <20151124111917.GO17050@phenom.ffwll.local> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 24, 2015 at 12:19:18PM +0100, Daniel Vetter wrote: > Downside: Tracking mapping changes on the guest side won't be any easier. > This is mostly a problem for integrated gpus, since discrete ones usually > require contiguous vram for scanout. I think saying "don't do that" is a > valid option though, i.e. we're assuming that page mappings for a in-use > scanout range never changes on the guest side. That is true for at least > all the current linux drivers. Apart from we already suffer limitations of fixed mappings and have patches that want to change the page mapping of active scanouts. -Chris -- Chris Wilson, Intel Open Source Technology Centre