From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35205) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2afk-0003Ed-5T for qemu-devel@nongnu.org; Thu, 03 Jul 2014 02:39:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X2afe-0000IO-Cy for qemu-devel@nongnu.org; Thu, 03 Jul 2014 02:39:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4072) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2afe-0000I7-4v for qemu-devel@nongnu.org; Thu, 03 Jul 2014 02:39:02 -0400 Date: Thu, 3 Jul 2014 09:40:52 +0300 From: "Michael S. Tsirkin" Message-ID: <20140703064052.GB20580@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> <53B4F0C4.5060209@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B4F0C4.5060209@intel.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: "Chen, Tiejun" 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" , Paolo Bonzini On Thu, Jul 03, 2014 at 01:57:24PM +0800, Chen, Tiejun wrote: > On 2014/7/2 23:27, Michael S. Tsirkin wrote: > >On Wed, Jul 02, 2014 at 03:15:02PM +0000, Ross Philipson wrote: > >>>-----Original Message----- > >>>From: Paolo Bonzini [mailto:pbonzini@redhat.com] > >>>Sent: Wednesday, July 02, 2014 7:33 AM > >>>To: Ross Philipson; Michael S. Tsirkin; Stefano Stabellini > >>>Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Allen M. > >>>Kay; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; > >>>yang.z.zhang@intel.com; anthony@codemonkey.ws; Anthony Perard; Chen, > >>>Tiejun > >>>Subject: Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough > >>>support > >>> > >>>Il 01/07/2014 19:39, Ross Philipson ha scritto: > >>>> > >>>>We do IGD pass-through in our project (XenClient). The patches > >>>>originally came from our project. We surface the same ISA bridge and > >>>>have never had activation issues on any version of Widows from XP to > >>>>Win8. We do not normally run server platforms so I can't say for sure > >>>>there. > >>> > >>>The problem is not activation, the problem is that the patches are > >>>making assumptions on the driver and the firmware that might work today > >>>but are IMHO just not sane. > >> > >>Sure I don't think anybody is suggesting that activation is > >>the main problem. It was just a potential problem with respect > >>to one of the proposed solutions. > >> > >>When we first started doing this (back in 2009ish) we ran into > >>all these problems with surfacing ISA bridges, giving guest > >>drivers access to registers in the host bridge. etc. Nothing seemed > >>sane; I sympathize. > > > >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 > > - 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. > > > >Tiejun, is there a chance this can be done not only > >on Linux but on windows as well? > > MST, > > Looks this is paravirtualizaed way, right? > > I can post this requirement to check but please make sure I really > understand what you mean, > > #1 We need to define a new Xen subsystem vendor id and emulate this value on > vga card > > #2 Native driver need to do: > > * if the subsystem id on vga is that emulated XEN subsystem id, the native > driver can get all necessary access including PCI host bridge at 0.0 and ISA > bridge at 1f.0 from second half of that emulated BAR0 double the real size. > > Right? If yes, I'd like to ask them. Yes. And in addition, get the device type from the low bits of the subsystem id as opposed to the ISA bridge. This way you don't need to modify the PC type at all. > But question is how to walk from PCI config on PCI host to BAR0 on VGA: > > dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0)); > > pci_write/read_config_dword(dev_priv->bridge_dev,,,) > > Thanks > Tiejun So you would have a helper: set dev_priv->bridge_dev to NULL, and then i915_write/read_host_dword(dev, dev_priv, offset) { if (dev_priv->bridge_dev) pci_write/read_config_dword(dev_priv->bridge_dev,,,) else iowrite/read16(dev->pv_io_base, ....) } The point being not touching anything except the vga device at all. Note: we can't allow guests to change the config of the real host bridge, so we end up whitelisting specific cards and specific registers anyway. So the only problem this solves is that of conflicts between the host bridge emulated by qemu and the hardware one. Also, maybe driver guys will see the pain this causes them and will put some pressure on the hardware guys to do it like this in future hardware :) > > > > > >>> > >>>I would have no problem with a clean patchset that adds a new machine > >>>type and doesn't touch code in "-M pc", but it looks like mst disagrees. > >>> Ultimately, if a patchset is too hacky for upstream, you can include > >>>it in your downstream XenClient (and XenServer) QEMU branch. It > >>>happens. > >>> > >>>Paolo > >>> > >>>----- > >>>No virus found in this message. > >>>Checked by AVG - www.avg.com > >>>Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date: > >>>06/30/14 > > 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: Thu, 3 Jul 2014 09:40:52 +0300 Message-ID: <20140703064052.GB20580@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> <53B4F0C4.5060209@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <53B4F0C4.5060209@intel.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: "Chen, Tiejun" 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" , Paolo Bonzini List-Id: xen-devel@lists.xenproject.org On Thu, Jul 03, 2014 at 01:57:24PM +0800, Chen, Tiejun wrote: > On 2014/7/2 23:27, Michael S. Tsirkin wrote: > >On Wed, Jul 02, 2014 at 03:15:02PM +0000, Ross Philipson wrote: > >>>-----Original Message----- > >>>From: Paolo Bonzini [mailto:pbonzini@redhat.com] > >>>Sent: Wednesday, July 02, 2014 7:33 AM > >>>To: Ross Philipson; Michael S. Tsirkin; Stefano Stabellini > >>>Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; Allen M. > >>>Kay; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; > >>>yang.z.zhang@intel.com; anthony@codemonkey.ws; Anthony Perard; Chen, > >>>Tiejun > >>>Subject: Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough > >>>support > >>> > >>>Il 01/07/2014 19:39, Ross Philipson ha scritto: > >>>> > >>>>We do IGD pass-through in our project (XenClient). The patches > >>>>originally came from our project. We surface the same ISA bridge and > >>>>have never had activation issues on any version of Widows from XP to > >>>>Win8. We do not normally run server platforms so I can't say for sure > >>>>there. > >>> > >>>The problem is not activation, the problem is that the patches are > >>>making assumptions on the driver and the firmware that might work today > >>>but are IMHO just not sane. > >> > >>Sure I don't think anybody is suggesting that activation is > >>the main problem. It was just a potential problem with respect > >>to one of the proposed solutions. > >> > >>When we first started doing this (back in 2009ish) we ran into > >>all these problems with surfacing ISA bridges, giving guest > >>drivers access to registers in the host bridge. etc. Nothing seemed > >>sane; I sympathize. > > > >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 > > - 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. > > > >Tiejun, is there a chance this can be done not only > >on Linux but on windows as well? > > MST, > > Looks this is paravirtualizaed way, right? > > I can post this requirement to check but please make sure I really > understand what you mean, > > #1 We need to define a new Xen subsystem vendor id and emulate this value on > vga card > > #2 Native driver need to do: > > * if the subsystem id on vga is that emulated XEN subsystem id, the native > driver can get all necessary access including PCI host bridge at 0.0 and ISA > bridge at 1f.0 from second half of that emulated BAR0 double the real size. > > Right? If yes, I'd like to ask them. Yes. And in addition, get the device type from the low bits of the subsystem id as opposed to the ISA bridge. This way you don't need to modify the PC type at all. > But question is how to walk from PCI config on PCI host to BAR0 on VGA: > > dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0)); > > pci_write/read_config_dword(dev_priv->bridge_dev,,,) > > Thanks > Tiejun So you would have a helper: set dev_priv->bridge_dev to NULL, and then i915_write/read_host_dword(dev, dev_priv, offset) { if (dev_priv->bridge_dev) pci_write/read_config_dword(dev_priv->bridge_dev,,,) else iowrite/read16(dev->pv_io_base, ....) } The point being not touching anything except the vga device at all. Note: we can't allow guests to change the config of the real host bridge, so we end up whitelisting specific cards and specific registers anyway. So the only problem this solves is that of conflicts between the host bridge emulated by qemu and the hardware one. Also, maybe driver guys will see the pain this causes them and will put some pressure on the hardware guys to do it like this in future hardware :) > > > > > >>> > >>>I would have no problem with a clean patchset that adds a new machine > >>>type and doesn't touch code in "-M pc", but it looks like mst disagrees. > >>> Ultimately, if a patchset is too hacky for upstream, you can include > >>>it in your downstream XenClient (and XenServer) QEMU branch. It > >>>happens. > >>> > >>>Paolo > >>> > >>>----- > >>>No virus found in this message. > >>>Checked by AVG - www.avg.com > >>>Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date: > >>>06/30/14 > >