From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39018) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X22QN-00039W-NH for qemu-devel@nongnu.org; Tue, 01 Jul 2014 14:05:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X22QI-0002k2-Nk for qemu-devel@nongnu.org; Tue, 01 Jul 2014 14:04:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7710) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X22QI-0002jv-Fb for qemu-devel@nongnu.org; Tue, 01 Jul 2014 14:04:54 -0400 Date: Tue, 1 Jul 2014 21:06:25 +0300 From: "Michael S. Tsirkin" Message-ID: <20140701180625.GC7640@redhat.com> References: <53B0D0C5.60000@intel.com> <20140630064822.GB14491@redhat.com> <53B110CA.6070606@intel.com> <20140630090511.GB15777@redhat.com> <53B1BAF9.6040800@citrix.com> <20140701053907.GA6108@redhat.com> <20140701170206.GB7640@redhat.com> <53B2F238.7000009@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <53B2F238.7000009@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" , "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 Tue, Jul 01, 2014 at 01:39:04PM -0400, Ross Philipson wrote: > On 07/01/2014 01:02 PM, Michael S. Tsirkin wrote: > >On Tue, Jul 01, 2014 at 05:47:39PM +0100, Stefano Stabellini wrote: > >>On Tue, 1 Jul 2014, Michael S. Tsirkin wrote: > >>>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 e= xisting > >>>>>>>>>>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 migrat= e i440fx to > >>>>>>>>>q35 as a PCIe machine of xen. > >>>>>>>> > >>>>>>>>That seems like a weak motivation. I don't see a need to get s= omething > >>>>>>>>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 chan= ges. > >>>>>Windows might request a new activation. > >>>> > >>>>That is a very good point. A while back I did a bunch of work to tr= y to keep > >>>>Windows activated between running an instance of Windows on bare me= tal and > >>>>as a VM. There were numerous bits of hardware and firmware that wen= t into > >>>>the calculation as to whether Windows thought it was the same platf= orm for > >>>>activation purposes. Changing the chipset sounds like a likely cand= idate for > >>>>inspection. Somewhere out there on the webs is a partial list of th= e things > >>>>that are inspected - lost the URL. > >>> > >>>It's not hard to try it out with kvm (you just need to remember to u= se ide 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. > >> > >>The page you linked is about Windows XP. Newer Windows versions have > >>stricter activation rules. I don't think that moving existing VM ima= ges > >>from piix to q35 could be done without extensive testing of all the > >>major existing operating system images. I certainly wouldn't rely on = a > >>wikipedia page for this. > > > >So do the testing then. > >You don't even need to do anything on xen - run them all on kvm. > >This testing will benefit everyone. > > > >BTW is there a chance that adding the ISA bridge or doing other > >tricks that Tiejun's patches do, will trigger windows activation? > >Looks like this logic can cut both ways. >=20 > We do IGD pass-through in our project (XenClient). The patches original= ly > came from our project. We surface the same ISA bridge and have never ha= d > activation issues on any version of Widows from XP to Win8. We do not > normally run server platforms so I can't say for sure there. What class does your ISA bridge device have? > > > >>Also I don't like the idea of tying Tiejun's patch series, that cover= s a > >>very narrow use case, to something as important and general purpose a= s > >>upgrading chipset. > > > >If it's true that implementing igd passthrough on top of q35 is much > >cleaner architecturally, then I don't see why we should merge a stop-g= ap > >solution that we'll need to then support indefinitely. > > > >We are talking about upstreaming functionality that xen already has, r= ight? > >So there's no time to market concern, whoever wants a solution today > >has it. Why not do it in the cleanest possible way? > > >=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 21:06:25 +0300 Message-ID: <20140701180625.GC7640@redhat.com> References: <53B0D0C5.60000@intel.com> <20140630064822.GB14491@redhat.com> <53B110CA.6070606@intel.com> <20140630090511.GB15777@redhat.com> <53B1BAF9.6040800@citrix.com> <20140701053907.GA6108@redhat.com> <20140701170206.GB7640@redhat.com> <53B2F238.7000009@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: <53B2F238.7000009@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" , "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 Tue, Jul 01, 2014 at 01:39:04PM -0400, Ross Philipson wrote: > On 07/01/2014 01:02 PM, Michael S. Tsirkin wrote: > >On Tue, Jul 01, 2014 at 05:47:39PM +0100, Stefano Stabellini wrote: > >>On Tue, 1 Jul 2014, Michael S. Tsirkin wrote: > >>>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 e= xisting > >>>>>>>>>>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 migrat= e i440fx to > >>>>>>>>>q35 as a PCIe machine of xen. > >>>>>>>> > >>>>>>>>That seems like a weak motivation. I don't see a need to get s= omething > >>>>>>>>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 chan= ges. > >>>>>Windows might request a new activation. > >>>> > >>>>That is a very good point. A while back I did a bunch of work to tr= y to keep > >>>>Windows activated between running an instance of Windows on bare me= tal and > >>>>as a VM. There were numerous bits of hardware and firmware that wen= t into > >>>>the calculation as to whether Windows thought it was the same platf= orm for > >>>>activation purposes. Changing the chipset sounds like a likely cand= idate for > >>>>inspection. Somewhere out there on the webs is a partial list of th= e things > >>>>that are inspected - lost the URL. > >>> > >>>It's not hard to try it out with kvm (you just need to remember to u= se ide 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. > >> > >>The page you linked is about Windows XP. Newer Windows versions have > >>stricter activation rules. I don't think that moving existing VM ima= ges > >>from piix to q35 could be done without extensive testing of all the > >>major existing operating system images. I certainly wouldn't rely on = a > >>wikipedia page for this. > > > >So do the testing then. > >You don't even need to do anything on xen - run them all on kvm. > >This testing will benefit everyone. > > > >BTW is there a chance that adding the ISA bridge or doing other > >tricks that Tiejun's patches do, will trigger windows activation? > >Looks like this logic can cut both ways. >=20 > We do IGD pass-through in our project (XenClient). The patches original= ly > came from our project. We surface the same ISA bridge and have never ha= d > activation issues on any version of Widows from XP to Win8. We do not > normally run server platforms so I can't say for sure there. What class does your ISA bridge device have? > > > >>Also I don't like the idea of tying Tiejun's patch series, that cover= s a > >>very narrow use case, to something as important and general purpose a= s > >>upgrading chipset. > > > >If it's true that implementing igd passthrough on top of q35 is much > >cleaner architecturally, then I don't see why we should merge a stop-g= ap > >solution that we'll need to then support indefinitely. > > > >We are talking about upstreaming functionality that xen already has, r= ight? > >So there's no time to market concern, whoever wants a solution today > >has it. Why not do it in the cleanest possible way? > > >=20 >=20 > --=20 > Ross Philipson