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

["Michael S. Tsirkin" <mst@xxxxxxxxxx>]

On Tue, Jul 01, 2014 at 01:39:04PM -0400, Ross Philipson wrote:
> On 07/01/2014 01:02 PM, 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.
> >
> >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.
> 
> We do IGD pass-through in our project (XenClient). The patches originally
> came from our project. We surface the same ISA bridge and have never had
> activation issues on any version of Widows from XP to Win8. We do not
> normally run server platforms so I can't say for sure there.

What class does your ISA bridge device have?

> >
> >>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?
> >
> 
> 
> -- 
> Ross Philipson

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel