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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

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

Cheers,

  Paul

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