[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
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. 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. > 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? -- MST _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |