qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
Date: Tue, 1 Jul 2014 08:39:07 +0300

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.



> >
> >_______________________________________________
> >Xen-devel mailing list
> >address@hidden
> >http://lists.xen.org/xen-devel
> >
> >-----
> >No virus found in this message.
> >Checked by AVG - www.avg.com
> >Version: 2014.0.4592 / Virus Database: 3986/7769 - Release Date: 06/30/14
> >
> 
> 
> -- 
> Ross Philipson



reply via email to

[Prev in Thread] Current Thread [Next in Thread]