From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2OnQ-0007Iu-Qu for qemu-devel@nongnu.org; Wed, 02 Jul 2014 13:58:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X2OnK-0003Vc-LQ for qemu-devel@nongnu.org; Wed, 02 Jul 2014 13:58:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20783) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2OnK-0003VX-Bw for qemu-devel@nongnu.org; Wed, 02 Jul 2014 13:58:10 -0400 Date: Wed, 2 Jul 2014 21:00:00 +0300 From: "Michael S. Tsirkin" Message-ID: <20140702180000.GB7841@redhat.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 Cc: "peter.maydell@linaro.org" , "xen-devel@lists.xensource.com" , "anthony@codemonkey.ws" , "Allen M. Kay" , "Kelly.Zytaruk@amd.com" , "qemu-devel@nongnu.org" , Anthony Perard , Stefano Stabellini , Ross Philipson , "yang.z.zhang@intel.com" , "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, Why won't it be? You just make one bit that is RO in hw RW in QEMU. > 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). Wasting IO isn't a good idea usually. > Xen can still add the hacky machine type if they want for existing > hosts, but this would be a nice way forward. > > Paolo We need to get agreement from driver writers though, specifically windows guys. -- MST From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support Date: Wed, 2 Jul 2014 21:00:00 +0300 Message-ID: <20140702180000.GB7841@redhat.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 Return-path: Content-Disposition: inline In-Reply-To: <53B43363.7090600@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Paolo Bonzini Cc: "peter.maydell@linaro.org" , "xen-devel@lists.xensource.com" , "anthony@codemonkey.ws" , "Allen M. Kay" , "Kelly.Zytaruk@amd.com" , "qemu-devel@nongnu.org" , Anthony Perard , Stefano Stabellini , Ross Philipson , "yang.z.zhang@intel.com" , "Chen, Tiejun" List-Id: xen-devel@lists.xenproject.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, Why won't it be? You just make one bit that is RO in hw RW in QEMU. > 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). Wasting IO isn't a good idea usually. > Xen can still add the hacky machine type if they want for existing > hosts, but this would be a nice way forward. > > Paolo We need to get agreement from driver writers though, specifically windows guys. -- MST