From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1Vxn-0006Bi-HS for qemu-devel@nongnu.org; Mon, 30 Jun 2014 03:25:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X1Vxe-0001h7-U0 for qemu-devel@nongnu.org; Mon, 30 Jun 2014 03:25:19 -0400 Received: from mga09.intel.com ([134.134.136.24]:19398) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1Vxe-0001g2-MX for qemu-devel@nongnu.org; Mon, 30 Jun 2014 03:25:10 -0400 Message-ID: <53B110CA.6070606@intel.com> Date: Mon, 30 Jun 2014 15:24:58 +0800 From: "Chen, Tiejun" MIME-Version: 1.0 References: <20140625084835.GF32652@redhat.com> <53AA8E7D.809@intel.com> <20140625090925.GH32652@redhat.com> <53AA9480.1010005@intel.com> <53AA96DF.6070501@redhat.com> <53AA9B58.6050803@intel.com> <53AA9C4E.9070506@redhat.com> <53ABE551.3080407@intel.com> <53ABF00E.6000309@redhat.com> <53B0D0C5.60000@intel.com> <20140630064822.GB14491@redhat.com> In-Reply-To: <20140630064822.GB14491@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: peter.maydell@linaro.org, xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com, allen.m.kay@intel.com, Kelly.Zytaruk@amd.com, qemu-devel@nongnu.org, yang.z.zhang@intel.com, anthony@codemonkey.ws, anthony.perard@citrix.com, Paolo Bonzini On 2014/6/30 14:48, Michael S. Tsirkin wrote: > On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote: >> On 2014/6/26 18:03, Paolo Bonzini wrote: >>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto: >>>> >>>>> >>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH >>>>> >>>> >>>> Are you saying the config space in the video device? >>> >>> No, I am saying in a new BAR, or at some magic offset of an existing >>> MMIO BAR. >>> >> >> As I mentioned previously, the IGD guy told me we have no any unused a >> offset or BAR in the config space. >> >> And guy who are responsible for the native driver seems not be accept to >> extend some magic offset of an existing MMIO BAR. >> >> In addition I think in a short time its not possible to migrate i440fx to >> q35 as a PCIe machine of xen. > > That seems like a weak motivation. I don't see a need to get something > merged upstream in a short time: this seems sure to miss 2.1, > so you have the time to make it architecturally sound. > "Making existing guests work" would be a better motivation. Yes. > Isn't this possible with an mch chipset? If you're saying q35, I mean AFAIK we have no any plan to migrate to this MCH in xen case. Additionally, I think I should follow this feature after q35 can work for xen scenario. > > >> So could we do this step by step: >> >> #1 phase: We just cover current qemu-xen implementation based on i44fx, so >> still provide that pseudo ISA bridge at 00:1f.0 as we already did. > > By the way there is no reason to put it at 00:1f.0 specifically I think. > So it seems simple: create a dummy device that gets device and > vendor id as properties. If you really like, add an option to get values Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge. There, we fake this device just at 00:1f.0. But you guys don't like this, and shouldn't this be just this point we discussing now? If you guys agree that , everything is fine. > from sysfs: device and vendor id are world readable, so just get them > directly and not through xen wrappers, this way you can open the files > RO and not RW. > You seem to poke at revision as well, I don't see > driver looking at that - strictly necessary? > If yes please patch host kernel to expose that info in sysfs, > though we can fall back on pci config if not there. > > MCH (bridge_dev) hacks in i915 are nastier. > To clean them up, we really have to have an explicit driver for this > bridge, not a pass-through device. Long term, the right thing to do is > likely to extend host driver and expose the necessary information in > sysfs on host kernel. > > I'm a bit confused. Any sysfs should be filled by the associated PCIe device, shouldn't it? So qemu still need to emulate this PCIe device firstly, then set properties into sysfs. > > >> #2 phase: Now, we will choose a capability ID that won't be conflicting with >> others. To do this properly, we need to get one from PCI SIG group. To have >> this workable and consistently validated, this method shouldn't be virt >> specific. Then native driver should use the same method. > > You mean you will be able to talk sense into hardware guys? > I doubt that. If they could be convinced to make e.g. i915 base a We're negotiating this, so this is just our long term solution we figure out currently. > proper BAR, why didn't they? We already have no any free BAR as we mentioned previously. > > >> So when xen work on >> q35 PCIe machine, we can walk this way. > > If you are emulating MCH anyway, pick one that is close > to what i915 driver expects. It would then work with existing Looks you guys prefer we create a new MCH anyway, right? But is it necessary to create a new based on i440fx just for a little change? Thanks Tiejun > devices, without new capability IDs. > > >> Anthony, >> >> Any comments to address this in xen case? >> >> Thanks >> Tiejun > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support Date: Mon, 30 Jun 2014 15:24:58 +0800 Message-ID: <53B110CA.6070606@intel.com> References: <20140625084835.GF32652@redhat.com> <53AA8E7D.809@intel.com> <20140625090925.GH32652@redhat.com> <53AA9480.1010005@intel.com> <53AA96DF.6070501@redhat.com> <53AA9B58.6050803@intel.com> <53AA9C4E.9070506@redhat.com> <53ABE551.3080407@intel.com> <53ABF00E.6000309@redhat.com> <53B0D0C5.60000@intel.com> <20140630064822.GB14491@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140630064822.GB14491@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: "Michael S. Tsirkin" Cc: peter.maydell@linaro.org, xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com, allen.m.kay@intel.com, Kelly.Zytaruk@amd.com, qemu-devel@nongnu.org, yang.z.zhang@intel.com, anthony@codemonkey.ws, anthony.perard@citrix.com, Paolo Bonzini List-Id: xen-devel@lists.xenproject.org On 2014/6/30 14:48, Michael S. Tsirkin wrote: > On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote: >> On 2014/6/26 18:03, Paolo Bonzini wrote: >>> Il 26/06/2014 11:18, Chen, Tiejun ha scritto: >>>> >>>>> >>>>> - offsets 0x0000..0x0fff map to configuration space of the host MCH >>>>> >>>> >>>> Are you saying the config space in the video device? >>> >>> No, I am saying in a new BAR, or at some magic offset of an existing >>> MMIO BAR. >>> >> >> As I mentioned previously, the IGD guy told me we have no any unused a >> offset or BAR in the config space. >> >> And guy who are responsible for the native driver seems not be accept to >> extend some magic offset of an existing MMIO BAR. >> >> In addition I think in a short time its not possible to migrate i440fx to >> q35 as a PCIe machine of xen. > > That seems like a weak motivation. I don't see a need to get something > merged upstream in a short time: this seems sure to miss 2.1, > so you have the time to make it architecturally sound. > "Making existing guests work" would be a better motivation. Yes. > Isn't this possible with an mch chipset? If you're saying q35, I mean AFAIK we have no any plan to migrate to this MCH in xen case. Additionally, I think I should follow this feature after q35 can work for xen scenario. > > >> So could we do this step by step: >> >> #1 phase: We just cover current qemu-xen implementation based on i44fx, so >> still provide that pseudo ISA bridge at 00:1f.0 as we already did. > > By the way there is no reason to put it at 00:1f.0 specifically I think. > So it seems simple: create a dummy device that gets device and > vendor id as properties. If you really like, add an option to get values Yes, this is just what we did in [Xen-devel] [v5][PATCH 2/5] xen, gfx passthrough: create pseudo intel isa bridge. There, we fake this device just at 00:1f.0. But you guys don't like this, and shouldn't this be just this point we discussing now? If you guys agree that , everything is fine. > from sysfs: device and vendor id are world readable, so just get them > directly and not through xen wrappers, this way you can open the files > RO and not RW. > You seem to poke at revision as well, I don't see > driver looking at that - strictly necessary? > If yes please patch host kernel to expose that info in sysfs, > though we can fall back on pci config if not there. > > MCH (bridge_dev) hacks in i915 are nastier. > To clean them up, we really have to have an explicit driver for this > bridge, not a pass-through device. Long term, the right thing to do is > likely to extend host driver and expose the necessary information in > sysfs on host kernel. > > I'm a bit confused. Any sysfs should be filled by the associated PCIe device, shouldn't it? So qemu still need to emulate this PCIe device firstly, then set properties into sysfs. > > >> #2 phase: Now, we will choose a capability ID that won't be conflicting with >> others. To do this properly, we need to get one from PCI SIG group. To have >> this workable and consistently validated, this method shouldn't be virt >> specific. Then native driver should use the same method. > > You mean you will be able to talk sense into hardware guys? > I doubt that. If they could be convinced to make e.g. i915 base a We're negotiating this, so this is just our long term solution we figure out currently. > proper BAR, why didn't they? We already have no any free BAR as we mentioned previously. > > >> So when xen work on >> q35 PCIe machine, we can walk this way. > > If you are emulating MCH anyway, pick one that is close > to what i915 driver expects. It would then work with existing Looks you guys prefer we create a new MCH anyway, right? But is it necessary to create a new based on i440fx just for a little change? Thanks Tiejun > devices, without new capability IDs. > > >> Anthony, >> >> Any comments to address this in xen case? >> >> Thanks >> Tiejun > >