From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42231) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1nkw-0006OO-U1 for qemu-devel@nongnu.org; Mon, 30 Jun 2014 22:25:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X1nkq-00081l-Ni for qemu-devel@nongnu.org; Mon, 30 Jun 2014 22:25:14 -0400 Received: from mga09.intel.com ([134.134.136.24]:60526) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1nkq-00081S-I4 for qemu-devel@nongnu.org; Mon, 30 Jun 2014 22:25:08 -0400 Message-ID: <53B21BF4.2080003@intel.com> Date: Tue, 01 Jul 2014 10:24:52 +0800 From: "Chen, Tiejun" MIME-Version: 1.0 References: <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> <53B110CA.6070606@intel.com> <20140630090511.GB15777@redhat.com> <53B1BAF9.6040800@citrix.com> In-Reply-To: <53B1BAF9.6040800@citrix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Ross Philipson , Stefano Stabellini , "Michael S. Tsirkin" Cc: "peter.maydell@linaro.org" , "xen-devel@lists.xensource.com" , "Allen M. Kay" , "Kelly.Zytaruk@amd.com" , "qemu-devel@nongnu.org" , Anthony Perard , Stefano Stabellini , "anthony@codemonkey.ws" , "yang.z.zhang@intel.com" , Paolo Bonzini On 2014/7/1 3:31, Ross Philipson wrote: > On 06/30/2014 03:22 PM, Stefano Stabellini wrote: >> On Mon, 30 Jun 2014, Michael S. Tsirkin wrote: >>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote: >>>> 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. >>> >>> So focus on this then. Existing guests will probably work >>> fine on a newer chipset - likely better than on i440fx. >>> xen management tools need to do some work to support this? >> >> Unfortunately existing Windows guests don't take well chipset changes. >> Windows might request a new activation. > > That is a very good point. A while back I did a bunch of work to try to > keep Windows activated between running an instance of Windows on bare > metal and as a VM. There were numerous bits of hardware and firmware > that went into the calculation as to whether Windows thought it was the > same platform for activation purposes. Changing the chipset sounds like > a likely candidate for inspection. Somewhere out there on the webs is a > partial list of the things that are inspected - lost the URL. > So do this mean currently we still can't go q35? Thanks Tiejun From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support Date: Tue, 01 Jul 2014 10:24:52 +0800 Message-ID: <53B21BF4.2080003@intel.com> References: <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> <53B110CA.6070606@intel.com> <20140630090511.GB15777@redhat.com> <53B1BAF9.6040800@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53B1BAF9.6040800@citrix.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: Ross Philipson , Stefano Stabellini , "Michael S. Tsirkin" Cc: "peter.maydell@linaro.org" , "xen-devel@lists.xensource.com" , "Allen M. Kay" , "Kelly.Zytaruk@amd.com" , "qemu-devel@nongnu.org" , Anthony Perard , Stefano Stabellini , "anthony@codemonkey.ws" , "yang.z.zhang@intel.com" , Paolo Bonzini List-Id: xen-devel@lists.xenproject.org On 2014/7/1 3:31, Ross Philipson wrote: > On 06/30/2014 03:22 PM, Stefano Stabellini wrote: >> On Mon, 30 Jun 2014, Michael S. Tsirkin wrote: >>> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote: >>>> 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. >>> >>> So focus on this then. Existing guests will probably work >>> fine on a newer chipset - likely better than on i440fx. >>> xen management tools need to do some work to support this? >> >> Unfortunately existing Windows guests don't take well chipset changes. >> Windows might request a new activation. > > That is a very good point. A while back I did a bunch of work to try to > keep Windows activated between running an instance of Windows on bare > metal and as a VM. There were numerous bits of hardware and firmware > that went into the calculation as to whether Windows thought it was the > same platform for activation purposes. Changing the chipset sounds like > a likely candidate for inspection. Somewhere out there on the webs is a > partial list of the things that are inspected - lost the URL. > So do this mean currently we still can't go q35? Thanks Tiejun