From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46467) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X22vZ-000358-Pz for qemu-devel@nongnu.org; Tue, 01 Jul 2014 14:37:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X22vU-0004xl-QA for qemu-devel@nongnu.org; Tue, 01 Jul 2014 14:37:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64205) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X22vU-0004xg-Gr for qemu-devel@nongnu.org; Tue, 01 Jul 2014 14:37:08 -0400 Date: Tue, 1 Jul 2014 21:38:54 +0300 From: "Michael S. Tsirkin" Message-ID: <20140701183854.GG7640@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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: Stefano Stabellini Cc: "peter.maydell@linaro.org" , "xen-devel@lists.xensource.com" , "anthony@codemonkey.ws" , "Allen M. Kay" , "Kelly.Zytaruk@amd.com" , "qemu-devel@nongnu.org" , Anthony Perard , Paul Durrant , Stefano Stabellini , Ross Philipson , "Chen, Tiejun" , "yang.z.zhang@intel.com" , Paolo Bonzini On Tue, Jul 01, 2014 at 07:20:26PM +0100, Stefano Stabellini wrote: > On Tue, 1 Jul 2014, 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 wrot= e: > > > > > >>>>>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 no= t be accept to > > > > > >>>>>extend some magic offset of an existing MMIO BAR. > > > > > >>>>> > > > > > >>>>>In addition I think in a short time its not possible to mi= grate i440fx to > > > > > >>>>>q35 as a PCIe machine of xen. > > > > > >>>> > > > > > >>>>That seems like a weak motivation. I don't see a need to g= et 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. > > > > >=20 > > > > > That is a very good point. A while back I did a bunch of work t= o try to keep > > > > > Windows activated between running an instance of Windows on bar= e 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 p= latform for > > > > > activation purposes. Changing the chipset sounds like a likely = candidate for > > > > > inspection. Somewhere out there on the webs is a partial list o= f the things > > > > > that are inspected - lost the URL. > > > >=20 > > > > It's not hard to try it out with kvm (you just need to remember t= o use ide with > > > > q35: ahci is the default there). I did, and windows did not ask = me to > > > > re-activate. > > > >=20 > > > > 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 > > > >=20 > > > >=20 > > > > 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) > > > >=20 > > > > So no, chipset version won't cause re-activation. > > >=20 > > > The page you linked is about Windows XP. Newer Windows versions hav= e > > > stricter activation rules. I don't think that moving existing VM i= mages > > > from piix to q35 could be done without extensive testing of all the > > > major existing operating system images. I certainly wouldn't rely o= n a > > > wikipedia page for this. > >=20 > > 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. >=20 > Sure, test results on KVM would be reusable for Xen and vice versa. > Indeed they would benefit everybody. I don't have the bandwidth for > this but I would encourage somebody in the community to step up and tes= t > Windows XP, Windows Vista, Winsows 7, Windows 8, Windows Server 2003, > Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012. >=20 > Paul, did I miss anything important? >=20 >=20 > > > Also I don't like the idea of tying Tiejun's patch series, that cov= ers a > > > very narrow use case, to something as important and general purpose= as > > > upgrading chipset. > >=20 > > 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-= gap > > solution that we'll need to then support indefinitely. > > > > We are talking about upstreaming functionality that xen already has, = right? > > 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 > I don't know if it is actually the case that building it on q35 would b= e > much cleaner architecturally. If it was true, it would be worth thinkin= g > about. However I don't know if we can ask Tiejun to undertake a task > that is significantly different and an order of magnitude bigger than > his current effort in order to upstream his series, that has a much > narrower scope. A simple solution would be for Tiejun to work on this support for kvm instead. Once someone else works to 1. Add mch support to Xen 2. Unify device assignment code Then Xen will get the feature for free. ;) --=20 MST 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:38:54 +0300 Message-ID: <20140701183854.GG7640@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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: 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: Stefano Stabellini Cc: "peter.maydell@linaro.org" , "xen-devel@lists.xensource.com" , "anthony@codemonkey.ws" , "Allen M. Kay" , "Kelly.Zytaruk@amd.com" , "qemu-devel@nongnu.org" , Anthony Perard , Paul Durrant , Stefano Stabellini , Ross Philipson , "Chen, Tiejun" , "yang.z.zhang@intel.com" , Paolo Bonzini List-Id: xen-devel@lists.xenproject.org On Tue, Jul 01, 2014 at 07:20:26PM +0100, Stefano Stabellini wrote: > On Tue, 1 Jul 2014, 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 wrot= e: > > > > > >>>>>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 no= t be accept to > > > > > >>>>>extend some magic offset of an existing MMIO BAR. > > > > > >>>>> > > > > > >>>>>In addition I think in a short time its not possible to mi= grate i440fx to > > > > > >>>>>q35 as a PCIe machine of xen. > > > > > >>>> > > > > > >>>>That seems like a weak motivation. I don't see a need to g= et 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. > > > > >=20 > > > > > That is a very good point. A while back I did a bunch of work t= o try to keep > > > > > Windows activated between running an instance of Windows on bar= e 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 p= latform for > > > > > activation purposes. Changing the chipset sounds like a likely = candidate for > > > > > inspection. Somewhere out there on the webs is a partial list o= f the things > > > > > that are inspected - lost the URL. > > > >=20 > > > > It's not hard to try it out with kvm (you just need to remember t= o use ide with > > > > q35: ahci is the default there). I did, and windows did not ask = me to > > > > re-activate. > > > >=20 > > > > 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 > > > >=20 > > > >=20 > > > > 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) > > > >=20 > > > > So no, chipset version won't cause re-activation. > > >=20 > > > The page you linked is about Windows XP. Newer Windows versions hav= e > > > stricter activation rules. I don't think that moving existing VM i= mages > > > from piix to q35 could be done without extensive testing of all the > > > major existing operating system images. I certainly wouldn't rely o= n a > > > wikipedia page for this. > >=20 > > 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. >=20 > Sure, test results on KVM would be reusable for Xen and vice versa. > Indeed they would benefit everybody. I don't have the bandwidth for > this but I would encourage somebody in the community to step up and tes= t > Windows XP, Windows Vista, Winsows 7, Windows 8, Windows Server 2003, > Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012. >=20 > Paul, did I miss anything important? >=20 >=20 > > > Also I don't like the idea of tying Tiejun's patch series, that cov= ers a > > > very narrow use case, to something as important and general purpose= as > > > upgrading chipset. > >=20 > > 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-= gap > > solution that we'll need to then support indefinitely. > > > > We are talking about upstreaming functionality that xen already has, = right? > > 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 > I don't know if it is actually the case that building it on q35 would b= e > much cleaner architecturally. If it was true, it would be worth thinkin= g > about. However I don't know if we can ask Tiejun to undertake a task > that is significantly different and an order of magnitude bigger than > his current effort in order to upstream his series, that has a much > narrower scope. A simple solution would be for Tiejun to work on this support for kvm instead. Once someone else works to 1. Add mch support to Xen 2. Unify device assignment code Then Xen will get the feature for free. ;) --=20 MST