From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33920) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X29V5-0005EQ-0A for qemu-devel@nongnu.org; Tue, 01 Jul 2014 21:38:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X29V0-00042a-0E for qemu-devel@nongnu.org; Tue, 01 Jul 2014 21:38:18 -0400 Received: from mga02.intel.com ([134.134.136.20]:14653) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X29Uz-00042B-Kz for qemu-devel@nongnu.org; Tue, 01 Jul 2014 21:38:13 -0400 Message-ID: <53B36268.90702@intel.com> Date: Wed, 02 Jul 2014 09:37:44 +0800 From: "Chen, Tiejun" MIME-Version: 1.0 References: <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> <20140701053907.GA6108@redhat.com> <20140701170206.GB7640@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 , "Michael S. Tsirkin" 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 , "yang.z.zhang@intel.com" , Paolo Bonzini On 2014/7/2 2:20, 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 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. >>>> >>>> It's not hard to try it out with kvm (you just need to remember to use 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—ROM / 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 images >>> 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. > > 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 test > Windows XP, Windows Vista, Winsows 7, Windows 8, Windows Server 2003, > Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012. > > Paul, did I miss anything important? > > >>> Also I don't like the idea of tying Tiejun's patch series, that covers a >>> very narrow use case, to something as important and general purpose as >>> 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-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? > > I don't know if it is actually the case that building it on q35 would be > much cleaner architecturally. If it was true, it would be worth thinking > about. However I don't know if we can ask Tiejun to undertake a task It really doesn't matter to me since this improvement is fine. But as you can image, I'm not sure how long/how much I can contribute to this task recently :) Sounds we will schedule a meeting to discuss this case, and maybe some of you guys would be invited as well. Once we have a workable plan, then we can do this step by step without any further arguments. Thanks Tiejun > 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. >