From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58389) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzjCo-0006MP-Hx for qemu-devel@nongnu.org; Wed, 25 Jun 2014 05:09:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WzjCe-0006Xf-UO for qemu-devel@nongnu.org; Wed, 25 Jun 2014 05:09:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:18949) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzjCe-0006Xa-M6 for qemu-devel@nongnu.org; Wed, 25 Jun 2014 05:09:16 -0400 Date: Wed, 25 Jun 2014 12:09:25 +0300 From: "Michael S. Tsirkin" Message-ID: <20140625090925.GH32652@redhat.com> References: <1403662641-28526-1-git-send-email-tiejun.chen@intel.com> <53AA69E7.8050406@redhat.com> <53AA7BD7.1080309@intel.com> <53AA7DCE.2030100@redhat.com> <20140625083121.GC32652@redhat.com> <53AA8ACF.3070101@redhat.com> <20140625084835.GF32652@redhat.com> <53AA8E7D.809@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53AA8E7D.809@intel.com> 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: "Chen, Tiejun" 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, anthony.perard@citrix.com, anthony@codemonkey.ws, yang.z.zhang@intel.com, Paolo Bonzini On Wed, Jun 25, 2014 at 04:55:25PM +0800, Chen, Tiejun wrote: > On 2014/6/25 16:48, Michael S. Tsirkin wrote: > >On Wed, Jun 25, 2014 at 10:39:43AM +0200, Paolo Bonzini wrote: > >>Il 25/06/2014 10:31, Michael S. Tsirkin ha scritto: > >>>It might be possible to move the Q35 bridge elsewhere. > >>>seabios doesn't care where the host bridge is. > >>>ACPI tables in QEMU can be adjusted. > >> > >>But why? It's always in 00:1f.0 on real hardware. If the i915 driver wants > >>to run under virtual machines, it should stop acting as if it knows what the > >>whole machine looks like. > >> > >>Paolo > > > >If guest driver can be fixed that seems ideal. > >I don't know how it works but presumably you guys do? > > Paolo prefer we need to fix this in the driver like: > > " > >>> The right way could be to make QEMU add a vendor-specific capability to > >>> the video device. The driver can probe for that capability before > >> > >> Do you mean we can pick two unused offsets in the configuration space of > >> the video device as a vendor-specific capability to hold the > >> vendor/device ids of the PCH? > > > > Yes, either that or add a new capability (which lets you choose the > > offsets more freely). > > > > If the IGD driver needs config space fields of the MCH, those fields > > could also be mirrored in the new capability. QEMU would forward them > > automatically. > > > > It could even be a new BAR, which gives even more freedom to allocate > > the fields. > " > > Thanks > Tiejun Adding a vendor-specific capability or BAR in an existing device is painful - hard to find free space for it. We could add a dummy device in PCI or ACPI, but driver should really look for it using device/vendor id, not at a specific address. What exactly is it that the driver wants to know? -- MST From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support Date: Wed, 25 Jun 2014 12:09:25 +0300 Message-ID: <20140625090925.GH32652@redhat.com> References: <1403662641-28526-1-git-send-email-tiejun.chen@intel.com> <53AA69E7.8050406@redhat.com> <53AA7BD7.1080309@intel.com> <53AA7DCE.2030100@redhat.com> <20140625083121.GC32652@redhat.com> <53AA8ACF.3070101@redhat.com> <20140625084835.GF32652@redhat.com> <53AA8E7D.809@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <53AA8E7D.809@intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Chen, Tiejun" 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, anthony.perard@citrix.com, anthony@codemonkey.ws, yang.z.zhang@intel.com, Paolo Bonzini List-Id: xen-devel@lists.xenproject.org On Wed, Jun 25, 2014 at 04:55:25PM +0800, Chen, Tiejun wrote: > On 2014/6/25 16:48, Michael S. Tsirkin wrote: > >On Wed, Jun 25, 2014 at 10:39:43AM +0200, Paolo Bonzini wrote: > >>Il 25/06/2014 10:31, Michael S. Tsirkin ha scritto: > >>>It might be possible to move the Q35 bridge elsewhere. > >>>seabios doesn't care where the host bridge is. > >>>ACPI tables in QEMU can be adjusted. > >> > >>But why? It's always in 00:1f.0 on real hardware. If the i915 driver wants > >>to run under virtual machines, it should stop acting as if it knows what the > >>whole machine looks like. > >> > >>Paolo > > > >If guest driver can be fixed that seems ideal. > >I don't know how it works but presumably you guys do? > > Paolo prefer we need to fix this in the driver like: > > " > >>> The right way could be to make QEMU add a vendor-specific capability to > >>> the video device. The driver can probe for that capability before > >> > >> Do you mean we can pick two unused offsets in the configuration space of > >> the video device as a vendor-specific capability to hold the > >> vendor/device ids of the PCH? > > > > Yes, either that or add a new capability (which lets you choose the > > offsets more freely). > > > > If the IGD driver needs config space fields of the MCH, those fields > > could also be mirrored in the new capability. QEMU would forward them > > automatically. > > > > It could even be a new BAR, which gives even more freedom to allocate > > the fields. > " > > Thanks > Tiejun Adding a vendor-specific capability or BAR in an existing device is painful - hard to find free space for it. We could add a dummy device in PCI or ACPI, but driver should really look for it using device/vendor id, not at a specific address. What exactly is it that the driver wants to know? -- MST