From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55096) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2FKT-00020l-UX for qemu-devel@nongnu.org; Wed, 02 Jul 2014 03:51:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X2FKO-0007gY-QJ for qemu-devel@nongnu.org; Wed, 02 Jul 2014 03:51:45 -0400 Received: from mga09.intel.com ([134.134.136.24]:48617) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2FKO-0007gS-DN for qemu-devel@nongnu.org; Wed, 02 Jul 2014 03:51:40 -0400 Message-ID: <53B3BA04.3070803@intel.com> Date: Wed, 02 Jul 2014 15:51:32 +0800 From: "Chen, Tiejun" MIME-Version: 1.0 References: <20140630064822.GB14491@redhat.com> <53B110CA.6070606@intel.com> <20140630090511.GB15777@redhat.com> <53B1BAF9.6040800@citrix.com> <20140701053907.GA6108@redhat.com> <20140701170206.GB7640@redhat.com> <53B36268.90702@intel.com> <20140702060920.GE3773@redhat.com> In-Reply-To: <20140702060920.GE3773@redhat.com> 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: "Michael S. Tsirkin" Cc: "peter.maydell@linaro.org" , "xen-devel@lists.xensource.com" , "anthony@codemonkey.ws" , Stefano Stabellini , "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 14:09, Michael S. Tsirkin wrote: > On Wed, Jul 02, 2014 at 09:37:44AM +0800, Chen, Tiejun wrote: >> 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 > > Would you like to start by creating a feature page for your project > on QEMU wiki? List design goals and non-goals. Which guests would you > like to work? Etc. Sorry, I'm already told I shouldn't do anymore before this meeting. > > Most importantly, include the issues raised on list with the latest > series. As it is I'm concerned that issues get mixed up with > suggestions for addressing them. I think you can issue your any requirement or opinions to discuss in the meeting. Then as a developer I'd like to follow that outcome of the meeting. 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. >>> > >