From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzjOP-0008Fq-Un for qemu-devel@nongnu.org; Wed, 25 Jun 2014 05:21:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WzjOH-0002QB-IP for qemu-devel@nongnu.org; Wed, 25 Jun 2014 05:21:25 -0400 Received: from mga09.intel.com ([134.134.136.24]:51125) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzjOH-0002Pt-CE for qemu-devel@nongnu.org; Wed, 25 Jun 2014 05:21:17 -0400 Message-ID: <53AA9480.1010005@intel.com> Date: Wed, 25 Jun 2014 17:21:04 +0800 From: "Chen, Tiejun" MIME-Version: 1.0 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> <20140625090925.GH32652@redhat.com> In-Reply-To: <20140625090925.GH32652@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, anthony.perard@citrix.com, anthony@codemonkey.ws, yang.z.zhang@intel.com, Paolo Bonzini On 2014/6/25 17:09, Michael S. Tsirkin wrote: > 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. Yes, this is a potential risk as well since we can't guarantee current free space is always valid for ever. > 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? > The i915 driver need to use the vendor/device ids to get what pch type is running, then go different paths. 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: Wed, 25 Jun 2014 17:21:04 +0800 Message-ID: <53AA9480.1010005@intel.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> <20140625090925.GH32652@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: <20140625090925.GH32652@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, anthony.perard@citrix.com, anthony@codemonkey.ws, yang.z.zhang@intel.com, Paolo Bonzini List-Id: xen-devel@lists.xenproject.org On 2014/6/25 17:09, Michael S. Tsirkin wrote: > 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. Yes, this is a potential risk as well since we can't guarantee current free space is always valid for ever. > 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? > The i915 driver need to use the vendor/device ids to get what pch type is running, then go different paths. Thanks Tiejun