From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55205) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2Nfu-0000V0-63 for qemu-devel@nongnu.org; Wed, 02 Jul 2014 12:46:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X2Nfl-0006AY-9k for qemu-devel@nongnu.org; Wed, 02 Jul 2014 12:46:26 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:44431) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2Nfl-0006AL-2Y for qemu-devel@nongnu.org; Wed, 02 Jul 2014 12:46:17 -0400 Date: Wed, 2 Jul 2014 12:45:37 -0400 From: Konrad Rzeszutek Wilk Message-ID: <20140702164537.GA2177@laptop.dumpdata.com> References: <53B1BAF9.6040800@citrix.com> <20140701053907.GA6108@redhat.com> <20140701170206.GB7640@redhat.com> <53B2F238.7000009@citrix.com> <53B3EDF5.4000802@redhat.com> <92B37F2487AE0841841737618F25AC1A3839EA4D@FTLPEX01CL03.citrite.net> <20140702152734.GA6687@redhat.com> <53B43363.7090600@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B43363.7090600@redhat.com> Subject: Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , arnes@virtuousgeek.org, daniel.vetter@ffwll.ch, airlied@redhat.com, jani.nikula@linux.intel.com, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: "peter.maydell@linaro.org" , "xen-devel@lists.xensource.com" , "anthony@codemonkey.ws" , "Michael S. Tsirkin" , "Allen M. Kay" , "Kelly.Zytaruk@amd.com" , "qemu-devel@nongnu.org" , "yang.z.zhang@intel.com" , Stefano Stabellini , Ross Philipson , Anthony Perard , "Chen, Tiejun" On Wed, Jul 02, 2014 at 06:29:23PM +0200, Paolo Bonzini wrote: > Il 02/07/2014 17:27, Michael S. Tsirkin ha scritto: > > At some level, maybe Paolo is right. Ignore existing drivers and ask > > intel developers to update their drivers to do something sane on > > hypervisors, even if they do ugly things on real hardware. > > > > A simple proposal since what I wrote earlier though apparently wasn't > > very clear: > > > > Detect Xen subsystem vendor id on vga card. > > If there, avoid poking at chipset. Instead > > - use subsystem device # for card type > > You mean for PCH type (aka PCH device id). > > > - use second half of BAR0 of device > > - instead of access to pci host > > > > hypervisors will simply take BAR0 and double it in size, > > make second part map to what would be the pci host. > > Nice. Detecting the backdoor via the subsystem vendor id > is clever. > > I'm not sure if it's possible to just double the size of BAR0 > or not, but my laptop has: > > Region 0: Memory at d0000000 (64-bit, non-prefetchable) [size=4M] > Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M] > Region 4: I/O ports at 5000 [size=64] > > and I hope we can reserve a few KB for hypervisors within those > 4M, or 8 bytes for an address/data pair (like cf8/cfc) within BAR4's > 64 bytes (or grow BAR4 to 128 bytes, or something like that). > > Xen can still add the hacky machine type if they want for existing > hosts, but this would be a nice way forward. It would be good to understand first why i915 in the first place needs to setup the bridge MBAR if it has not been set. As in, why is this region needed? Is it needed to flush the pipeline (as in you need to write there?) or .. Perhaps it is not needed anymore with the current hardware and what can be done is put a stake in the ground saying that only genX or later will be supported. The commit ids allude to power managament and the earlier commits did poke there - but I don't see it on the latest tree. > > Paolo > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support Date: Wed, 2 Jul 2014 12:45:37 -0400 Message-ID: <20140702164537.GA2177@laptop.dumpdata.com> References: <53B1BAF9.6040800@citrix.com> <20140701053907.GA6108@redhat.com> <20140701170206.GB7640@redhat.com> <53B2F238.7000009@citrix.com> <53B3EDF5.4000802@redhat.com> <92B37F2487AE0841841737618F25AC1A3839EA4D@FTLPEX01CL03.citrite.net> <20140702152734.GA6687@redhat.com> <53B43363.7090600@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <53B43363.7090600@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Paolo Bonzini , arnes@virtuousgeek.org, daniel.vetter@ffwll.ch, airlied@redhat.com, jani.nikula@linux.intel.com, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: "peter.maydell@linaro.org" , "xen-devel@lists.xensource.com" , "anthony@codemonkey.ws" , "Michael S. Tsirkin" , "Kelly.Zytaruk@amd.com" , "qemu-devel@nongnu.org" , "yang.z.zhang@intel.com" , Stefano Stabellini , Ross Philipson , Anthony Perard , "Chen, Tiejun" List-Id: dri-devel@lists.freedesktop.org On Wed, Jul 02, 2014 at 06:29:23PM +0200, Paolo Bonzini wrote: > Il 02/07/2014 17:27, Michael S. Tsirkin ha scritto: > > At some level, maybe Paolo is right. Ignore existing drivers and ask > > intel developers to update their drivers to do something sane on > > hypervisors, even if they do ugly things on real hardware. > > > > A simple proposal since what I wrote earlier though apparently wasn't > > very clear: > > > > Detect Xen subsystem vendor id on vga card. > > If there, avoid poking at chipset. Instead > > - use subsystem device # for card type > > You mean for PCH type (aka PCH device id). > > > - use second half of BAR0 of device > > - instead of access to pci host > > > > hypervisors will simply take BAR0 and double it in size, > > make second part map to what would be the pci host. > > Nice. Detecting the backdoor via the subsystem vendor id > is clever. > > I'm not sure if it's possible to just double the size of BAR0 > or not, but my laptop has: > > Region 0: Memory at d0000000 (64-bit, non-prefetchable) [size=4M] > Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M] > Region 4: I/O ports at 5000 [size=64] > > and I hope we can reserve a few KB for hypervisors within those > 4M, or 8 bytes for an address/data pair (like cf8/cfc) within BAR4's > 64 bytes (or grow BAR4 to 128 bytes, or something like that). > > Xen can still add the hacky machine type if they want for existing > hosts, but this would be a nice way forward. It would be good to understand first why i915 in the first place needs to setup the bridge MBAR if it has not been set. As in, why is this region needed? Is it needed to flush the pipeline (as in you need to write there?) or .. Perhaps it is not needed anymore with the current hardware and what can be done is put a stake in the ground saying that only genX or later will be supported. The commit ids allude to power managament and the earlier commits did poke there - but I don't see it on the latest tree. > > Paolo > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel