From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34257) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X05p1-000403-Uc for qemu-devel@nongnu.org; Thu, 26 Jun 2014 05:18:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X05ot-0007vl-EV for qemu-devel@nongnu.org; Thu, 26 Jun 2014 05:18:23 -0400 Received: from mga03.intel.com ([143.182.124.21]:20346) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X05ot-0007uJ-9I for qemu-devel@nongnu.org; Thu, 26 Jun 2014 05:18:15 -0400 Message-ID: <53ABE551.3080407@intel.com> Date: Thu, 26 Jun 2014 17:18:09 +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> <53AA9480.1010005@intel.com> <53AA96DF.6070501@redhat.com> <53AA9B58.6050803@intel.com> <53AA9C4E.9070506@redhat.com> In-Reply-To: <53AA9C4E.9070506@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: Paolo Bonzini , "Michael S. Tsirkin" Cc: peter.maydell@linaro.org, xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com, allen.m.kay@intel.com, qemu-devel@nongnu.org, Kelly.Zytaruk@amd.com, anthony.perard@citrix.com, anthony@codemonkey.ws, yang.z.zhang@intel.com On 2014/6/25 17:54, Paolo Bonzini wrote: > Il 25/06/2014 11:50, Chen, Tiejun ha scritto: >>> >>> For past devices, we know which BARs they use. For future devices, it >>> would be nice if the PCH/MCH backdoor was specified so that we know they >>> will leave a free BAR for virtualization. >>> >> >> Now I'm a bit confused about BAR here. >> >> You're saying we will reserve a free BAR to address those information to >> expose to guest, but which device does this free BAR belong to? The >> video device? Or PCH/MCH? > > The video device. If the host device does not have the BAR (which will > be the common case), QEMU can emulate it like this: According to some feedback, neither we have any unused PCI unused config offset, nor BAR. > > - offsets 0x0000..0x0fff map to configuration space of the host MCH > Are you saying the config space in the video device? but will this overlap? Every PCIe device already have a 4K config space, right? So we should extend these two ranges: 0x0000..0x0fff: the standard PCIe config space in the video device 0x1000..0x1fff: map to configuration of the real host bridge 0x2000..0x2fff: map to configuration of the real ISA bridge Right? But as you know, we just need to expose a little config space from the real host bridge and the real ISA bridge, so this may be waste with 8K. Thanks Tiejun > - offsets 0x1000..0x1fff map to configuration space of the host PCH > > Of course this is only limited to offsets that are needed by the driver. > > Paolo > > 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: Thu, 26 Jun 2014 17:18:09 +0800 Message-ID: <53ABE551.3080407@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> <53AA9480.1010005@intel.com> <53AA96DF.6070501@redhat.com> <53AA9B58.6050803@intel.com> <53AA9C4E.9070506@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: <53AA9C4E.9070506@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 , "Michael S. Tsirkin" Cc: peter.maydell@linaro.org, xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com, allen.m.kay@intel.com, qemu-devel@nongnu.org, Kelly.Zytaruk@amd.com, anthony.perard@citrix.com, anthony@codemonkey.ws, yang.z.zhang@intel.com List-Id: xen-devel@lists.xenproject.org On 2014/6/25 17:54, Paolo Bonzini wrote: > Il 25/06/2014 11:50, Chen, Tiejun ha scritto: >>> >>> For past devices, we know which BARs they use. For future devices, it >>> would be nice if the PCH/MCH backdoor was specified so that we know they >>> will leave a free BAR for virtualization. >>> >> >> Now I'm a bit confused about BAR here. >> >> You're saying we will reserve a free BAR to address those information to >> expose to guest, but which device does this free BAR belong to? The >> video device? Or PCH/MCH? > > The video device. If the host device does not have the BAR (which will > be the common case), QEMU can emulate it like this: According to some feedback, neither we have any unused PCI unused config offset, nor BAR. > > - offsets 0x0000..0x0fff map to configuration space of the host MCH > Are you saying the config space in the video device? but will this overlap? Every PCIe device already have a 4K config space, right? So we should extend these two ranges: 0x0000..0x0fff: the standard PCIe config space in the video device 0x1000..0x1fff: map to configuration of the real host bridge 0x2000..0x2fff: map to configuration of the real ISA bridge Right? But as you know, we just need to expose a little config space from the real host bridge and the real ISA bridge, so this may be waste with 8K. Thanks Tiejun > - offsets 0x1000..0x1fff map to configuration space of the host PCH > > Of course this is only limited to offsets that are needed by the driver. > > Paolo > >