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

["Chen, Tiejun" <tiejun.chen@intel.com>]

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

> 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.
>