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 14:09, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 09:37:44AM +0800, Chen, Tiejun wrote:
>> 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
>
> Would you like to start by creating a feature page for your project
> on QEMU wiki?  List design goals and non-goals.  Which guests would you
> like to work? Etc.

Sorry, I'm already told I shouldn't do anymore before this meeting.

>
> Most importantly, include the issues raised on list with the latest
> series.  As it is I'm concerned that issues get mixed up with
> suggestions for addressing them.

I think you can issue your any requirement or opinions to discuss in the 
meeting. Then as a developer I'd like to follow that outcome of the meeting.

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