Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

["Michael S. Tsirkin" <mst@redhat.com>]

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