From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39667) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1qmg-00046x-Vg for qemu-devel@nongnu.org; Tue, 01 Jul 2014 01:39:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X1qmc-0000dY-Tl for qemu-devel@nongnu.org; Tue, 01 Jul 2014 01:39:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9220) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1qmc-0000dI-LM for qemu-devel@nongnu.org; Tue, 01 Jul 2014 01:39:10 -0400 Date: Tue, 1 Jul 2014 08:39:07 +0300 From: "Michael S. Tsirkin" Message-ID: <20140701053907.GA6108@redhat.com> References: <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=utf-8 Content-Disposition: inline In-Reply-To: <53B1BAF9.6040800@citrix.com> Content-Transfer-Encoding: quoted-printable 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 Cc: "peter.maydell@linaro.org" , "xen-devel@lists.xensource.com" , Stefano Stabellini , "Allen M. Kay" , "Kelly.Zytaruk@amd.com" , "qemu-devel@nongnu.org" , Anthony Perard , Stefano Stabellini , "anthony@codemonkey.ws" , "Chen, Tiejun" , "yang.z.zhang@intel.com" , Paolo Bonzini On Mon, Jun 30, 2014 at 03:31:05PM -0400, 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 exist= ing > >>>>>>MMIO BAR. > >>>>>> > >>>>> > >>>>>As I mentioned previously, the IGD guy told me we have no any unus= ed a > >>>>>offset or BAR in the config space. > >>>>> > >>>>>And guy who are responsible for the native driver seems not be acc= ept to > >>>>>extend some magic offset of an existing MMIO BAR. > >>>>> > >>>>>In addition I think in a short time its not possible to migrate i4= 40fx to > >>>>>q35 as a PCIe machine of xen. > >>>> > >>>>That seems like a weak motivation. I don't see a need to get somet= hing > >>>>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. >=20 > 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 in= to > the calculation as to whether Windows thought it was the same platform = for > activation purposes. Changing the chipset sounds like a likely candidat= e for > inspection. Somewhere out there on the webs is a partial list of the th= ings > that are inspected - lost the URL. It's not hard to try it out with kvm (you just need to remember to use id= e with q35: ahci is the default there). I did, and windows did not ask me to re-activate. The detailed info is not hard to find: http://en.wikipedia.org/wiki/Microsoft_Product_Activation links to: http://technet.microsoft.com/en-us/library/bb457054.aspx 1 Display Adapter 00010 (5) 2 SCSI Adapter 00011 (5) 3 IDE Adapter 0011 (4) 4 Network Adapter MAC Address 1001011000 (10) 5 RAM Amount Range (i.e. 0-64mb, 64-128mb, etc) 101 (3) 6 Processor Type 011 (3) 7 Processor Serial Number 000000 (6) 8 Hard Drive Device 1101100 (7) 9 Hard Drive Volume Serial Number 1001000001 (10) 10 CD=E2=80=94ROM / CD-RW / DVD-ROM 010111 (6) - "Dockable" 0 (1) - Hardware Hash version (version of algorithm used) 001 (3) So no, chipset version won't cause re-activation. > > > >_______________________________________________ > >Xen-devel mailing list > >Xen-devel@lists.xen.org > >http://lists.xen.org/xen-devel > > > >----- > >No virus found in this message. > >Checked by AVG - www.avg.com > >Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date: 06/30= /14 > > >=20 >=20 > --=20 > Ross Philipson From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support Date: Tue, 1 Jul 2014 08:39:07 +0300 Message-ID: <20140701053907.GA6108@redhat.com> References: <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=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline 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 Cc: "peter.maydell@linaro.org" , "xen-devel@lists.xensource.com" , Stefano Stabellini , "Allen M. Kay" , "Kelly.Zytaruk@amd.com" , "qemu-devel@nongnu.org" , Anthony Perard , Stefano Stabellini , "anthony@codemonkey.ws" , "Chen, Tiejun" , "yang.z.zhang@intel.com" , Paolo Bonzini List-Id: xen-devel@lists.xenproject.org On Mon, Jun 30, 2014 at 03:31:05PM -0400, 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 exist= ing > >>>>>>MMIO BAR. > >>>>>> > >>>>> > >>>>>As I mentioned previously, the IGD guy told me we have no any unus= ed a > >>>>>offset or BAR in the config space. > >>>>> > >>>>>And guy who are responsible for the native driver seems not be acc= ept to > >>>>>extend some magic offset of an existing MMIO BAR. > >>>>> > >>>>>In addition I think in a short time its not possible to migrate i4= 40fx to > >>>>>q35 as a PCIe machine of xen. > >>>> > >>>>That seems like a weak motivation. I don't see a need to get somet= hing > >>>>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. >=20 > 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 in= to > the calculation as to whether Windows thought it was the same platform = for > activation purposes. Changing the chipset sounds like a likely candidat= e for > inspection. Somewhere out there on the webs is a partial list of the th= ings > that are inspected - lost the URL. It's not hard to try it out with kvm (you just need to remember to use id= e with q35: ahci is the default there). I did, and windows did not ask me to re-activate. The detailed info is not hard to find: http://en.wikipedia.org/wiki/Microsoft_Product_Activation links to: http://technet.microsoft.com/en-us/library/bb457054.aspx 1 Display Adapter 00010 (5) 2 SCSI Adapter 00011 (5) 3 IDE Adapter 0011 (4) 4 Network Adapter MAC Address 1001011000 (10) 5 RAM Amount Range (i.e. 0-64mb, 64-128mb, etc) 101 (3) 6 Processor Type 011 (3) 7 Processor Serial Number 000000 (6) 8 Hard Drive Device 1101100 (7) 9 Hard Drive Volume Serial Number 1001000001 (10) 10 CD=E2=80=94ROM / CD-RW / DVD-ROM 010111 (6) - "Dockable" 0 (1) - Hardware Hash version (version of algorithm used) 001 (3) So no, chipset version won't cause re-activation. > > > >_______________________________________________ > >Xen-devel mailing list > >Xen-devel@lists.xen.org > >http://lists.xen.org/xen-devel > > > >----- > >No virus found in this message. > >Checked by AVG - www.avg.com > >Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date: 06/30= /14 > > >=20 >=20 > --=20 > Ross Philipson