Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream

[Kevin Stange <kevin@xxxxxxxxxxxxx>]

On 01/05/2018 03:03 AM, Paul Durrant wrote:
>> -----Original Message-----
>> From: Kevin Stange [mailto:kevin@xxxxxxxxxxxxx]
>> Sent: 04 January 2018 21:17
>> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
>> Cc: George Dunlap <George.Dunlap@xxxxxxxxxx>; xen-
>> devel@xxxxxxxxxxxxxxxxxxxx; Anthony Perard <anthony.perard@xxxxxxxxxx>
>> Subject: Re: [Xen-devel] PCI Device Subtree Change from Traditional to
>> Upstream
>>
>> On 01/04/2018 07:26 AM, Paul Durrant wrote:
>>>> -----Original Message-----
>>>> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On
>> Behalf
>>>> Of Anthony PERARD
>>>> Sent: 04 January 2018 12:52
>>>> To: Kevin Stange <kevin@xxxxxxxxxxxxx>
>>>> Cc: George Dunlap <George.Dunlap@xxxxxxxxxx>; xen-
>>>> devel@xxxxxxxxxxxxxxxxxxxx
>>>> Subject: Re: [Xen-devel] PCI Device Subtree Change from Traditional to
>>>> Upstream
>>>>
>>>> On Wed, Jan 03, 2018 at 05:10:54PM -0600, Kevin Stange wrote:
>>>>> On 01/03/2018 11:57 AM, Anthony PERARD wrote:
>>>>>> On Wed, Dec 20, 2017 at 11:40:03AM -0600, Kevin Stange wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I've been working on transitioning a number of Windows guests
>> under
>>>> HVM
>>>>>>> from using QEMU traditional to QEMU upstream as is recommended
>> in
>>>> the
>>>>>>> documentation.  When I move these guests, the PCI subtree for Xen
>>>>>>> devices changes and Windows creates a totally new copy of each
>>>> device.
>>>>>>> Windows tracks down the storage without issue, but it treats the new
>>>>>>> instance of the NIC driver as a new device and clears the network
>>>>>>> configuration even though the MAC address is unchanged.  Manually
>>>>>>> booting the guest back on the traditional device model reactivates the
>>>>>>> original PCI subtree and the old network configuration with it.
>>>>>>>
>>>>>>> The only thing that I have been able to find that's substantially
>>>>>>> different comparing the device trees is that the device instance ID
>>>>>>> values differ on the parent Xen PCI device:
>>>>>>>
>>>>>>>
>>>>
>> PCI\VEN_5853&DEV_0001&SUBSYS_00015853&REV_01\3&267A616A&3&18
>>>>>>>
>>>>>>>
>>>>
>> PCI\VEN_5853&DEV_0001&SUBSYS_00015853&REV_01\3&267A616A&3&10
>>>>>>>
>>>>>>> Besides actually setting the guest to boot using QEMU traditional, is
>>>>>>> there a way to convince Windows to treat these devices as the same?
>> A
>>>>>>> patch-based solution would be acceptable to me if there is one, but I
>>>>>>> don't understand the code well enough to create my own solution.
>>>
>>> Kevin,
>>>
>>> I missed the original email as it went past...
>>>
>>> Are Xen Project PV drivers installed in the guest? And are you talking about
>> a PV NIC device or an emulated device?
>>
>> These guests use some of the older Xen PV drivers with a PV NIC, not an
>> emulated device.
>>
> 
> Ok. I was curious because the latest PV drivers contain a hack (that was 
> actually suggested by someone at Microsoft) to make sure that (as far as the 
> Windows PnP subsystem is concerned) the Xen platform device never moves once 
> the XENBUS driver has been installed. This is done by installing a filter 
> driver onto Windows' PCI bus driver that spots the platform device and 
> re-writes the trailing 'uniquifier' to be exactly what it was at the time of 
> driver installation.
> So, if you update your VMs to use newer PV drivers first, then you should be 
> immune to the platform device moving on the bus.

This is interesting and good to learn, but I had a lot of trouble in the
past trying to convert existing guests to use the modern PV drivers, due
to difficulties completely removing the old ones and getting Windows to
adopt the new ones.  The resulting mess is more work than dealing with
the current problem, which is why it would be nice to be able to just
massage the Windows guests to the desired configuration from outside.

-- 
Kevin Stange
Chief Technology Officer
Steadfast | Managed Infrastructure, Datacenter and Cloud Services
800 S Wells, Suite 190 | Chicago, IL 60607
312.602.2689 X203 | Fax: 312.602.2688
kevin@xxxxxxxxxxxxx | www.steadfast.net

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel