* PCI Device Subtree Change from Traditional to Upstream @ 2017-12-20 17:40 Kevin Stange 2017-12-20 17:44 ` George Dunlap 2018-01-03 17:57 ` Anthony PERARD 0 siblings, 2 replies; 20+ messages in thread From: Kevin Stange @ 2017-12-20 17:40 UTC (permalink / raw) To: xen-devel 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 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@steadfast.net | www.steadfast.net _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PCI Device Subtree Change from Traditional to Upstream 2017-12-20 17:40 PCI Device Subtree Change from Traditional to Upstream Kevin Stange @ 2017-12-20 17:44 ` George Dunlap 2018-01-03 17:57 ` Anthony PERARD 1 sibling, 0 replies; 20+ messages in thread From: George Dunlap @ 2017-12-20 17:44 UTC (permalink / raw) To: Kevin Stange; +Cc: xen-devel On Wed, Dec 20, 2017 at 5:40 PM, Kevin Stange <kevin@steadfast.net> 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. Paul, Any idea on this? Thanks, -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PCI Device Subtree Change from Traditional to Upstream 2017-12-20 17:40 PCI Device Subtree Change from Traditional to Upstream Kevin Stange 2017-12-20 17:44 ` George Dunlap @ 2018-01-03 17:57 ` Anthony PERARD 2018-01-03 23:10 ` Kevin Stange 1 sibling, 1 reply; 20+ messages in thread From: Anthony PERARD @ 2018-01-03 17:57 UTC (permalink / raw) To: Kevin Stange; +Cc: George Dunlap, xen-devel 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. Hi Kevin, I've got a patch to QEMU that seems to do the trick: From: Anthony PERARD <anthony.perard@citrix.com> Subject: [PATCH] xen-platform: Hardcode PCI slot to 3 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- hw/i386/pc_piix.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index 5e47528993..93e3a9a916 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -405,7 +405,7 @@ static void pc_xen_hvm_init(MachineState *machine) bus = pci_find_primary_bus(); if (bus != NULL) { - pci_create_simple(bus, -1, "xen-platform"); + pci_create_simple(bus, PCI_DEVFN(3, 0), "xen-platform"); } } #endif The same thing could be done by libxl, by providing specific command line options to qemu. (I think that could even be done via a different config file for the guest.) Regards, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: PCI Device Subtree Change from Traditional to Upstream 2018-01-03 17:57 ` Anthony PERARD @ 2018-01-03 23:10 ` Kevin Stange 2018-01-04 12:52 ` Anthony PERARD 0 siblings, 1 reply; 20+ messages in thread From: Kevin Stange @ 2018-01-03 23:10 UTC (permalink / raw) To: Anthony PERARD; +Cc: George Dunlap, xen-devel 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. > > Hi Kevin, > > I've got a patch to QEMU that seems to do the trick: > > From: Anthony PERARD <anthony.perard@citrix.com> > Subject: [PATCH] xen-platform: Hardcode PCI slot to 3 > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> > --- > hw/i386/pc_piix.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c > index 5e47528993..93e3a9a916 100644 > --- a/hw/i386/pc_piix.c > +++ b/hw/i386/pc_piix.c > @@ -405,7 +405,7 @@ static void pc_xen_hvm_init(MachineState *machine) > > bus = pci_find_primary_bus(); > if (bus != NULL) { > - pci_create_simple(bus, -1, "xen-platform"); > + pci_create_simple(bus, PCI_DEVFN(3, 0), "xen-platform"); > } > } > #endif > > > The same thing could be done by libxl, by providing specific command > line options to qemu. (I think that could even be done via a different > config file for the guest.) This patch doesn't seem to work for me. It seems like the device model process is exiting immediately, but I haven't been able to find any information as to what is going wrong. I tested with Xen 4.6.6 and the QEMU packaged with that release. Should I try it on a different version of Xen and QEMU? -- 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@steadfast.net | www.steadfast.net _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PCI Device Subtree Change from Traditional to Upstream 2018-01-03 23:10 ` Kevin Stange @ 2018-01-04 12:52 ` Anthony PERARD 2018-01-04 13:26 ` Paul Durrant ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Anthony PERARD @ 2018-01-04 12:52 UTC (permalink / raw) To: Kevin Stange; +Cc: George Dunlap, xen-devel 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. > > > > Hi Kevin, > > > > I've got a patch to QEMU that seems to do the trick: > > > > From: Anthony PERARD <anthony.perard@citrix.com> > > Subject: [PATCH] xen-platform: Hardcode PCI slot to 3 > > > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> > > --- > > hw/i386/pc_piix.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c > > index 5e47528993..93e3a9a916 100644 > > --- a/hw/i386/pc_piix.c > > +++ b/hw/i386/pc_piix.c > > @@ -405,7 +405,7 @@ static void pc_xen_hvm_init(MachineState *machine) > > > > bus = pci_find_primary_bus(); > > if (bus != NULL) { > > - pci_create_simple(bus, -1, "xen-platform"); > > + pci_create_simple(bus, PCI_DEVFN(3, 0), "xen-platform"); > > } > > } > > #endif > > > > > > The same thing could be done by libxl, by providing specific command > > line options to qemu. (I think that could even be done via a different > > config file for the guest.) > > This patch doesn't seem to work for me. It seems like the device model > process is exiting immediately, but I haven't been able to find any > information as to what is going wrong. I tested with Xen 4.6.6 and the > QEMU packaged with that release. Should I try it on a different version > of Xen and QEMU? What this patch does is asking QEMU to insert the PCI card "xen-platform" into the 3rd PCI slot. My guess is that failed because there is already a PCI device there. You could check qemu's logs, it's in /var/log/xen/qemu-dm-${guest_name}.log Let's try something else, instead of patching QEMU, we can patch libxl, that might work better. Can you try this patch? (I've only test compiled.) I've write the patch for Xen 4.6, since that the version you are using. From: Anthony PERARD <anthony.perard@citrix.com> Subject: [PATCH] libxl_dm: Explicitly put xen-platform device on PCI slot 3 In order to do that, we don't use xenfv machine anymore and explicity add the platform device on the command line. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- tools/libxl/libxl_dm.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index 0db5f13553..59c0102a3e 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -899,6 +899,11 @@ static int libxl__build_device_model_args_new(libxl__gc *gc, } } + if (libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) { + flexarray_vappend(dm_args, "-device", + "xen-platform,addr=3", NULL); + } + if (libxl_defbool_val(b_info->u.hvm.nographic) && (!sdl && !vnc)) { flexarray_append(dm_args, "-nographic"); } @@ -1075,14 +1080,10 @@ static int libxl__build_device_model_args_new(libxl__gc *gc, flexarray_append(dm_args, b_info->extra_pv[i]); break; case LIBXL_DOMAIN_TYPE_HVM: - if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) { /* Switching here to the machine "pc" which does not add * the xen-platform device instead of the default "xenfv" machine. */ - machinearg = libxl__sprintf(gc, "pc,accel=xen"); - } else { - machinearg = libxl__sprintf(gc, "xenfv"); - } + machinearg = libxl__sprintf(gc, "pc,accel=xen"); if (b_info->u.hvm.mmio_hole_memkb) { uint64_t max_ram_below_4g = (1ULL << 32) - (b_info->u.hvm.mmio_hole_memkb << 10); -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: PCI Device Subtree Change from Traditional to Upstream 2018-01-04 12:52 ` Anthony PERARD @ 2018-01-04 13:26 ` Paul Durrant 2018-01-04 21:17 ` Kevin Stange 2018-01-04 21:16 ` Kevin Stange 2018-01-25 17:54 ` George Dunlap 2 siblings, 1 reply; 20+ messages in thread From: Paul Durrant @ 2018-01-04 13:26 UTC (permalink / raw) To: Kevin Stange Cc: Anthony Perard, xen-devel@lists.xenproject.org, George Dunlap > -----Original Message----- > From: Xen-devel [mailto:xen-devel-bounces@lists.xenproject.org] On Behalf > Of Anthony PERARD > Sent: 04 January 2018 12:52 > To: Kevin Stange <kevin@steadfast.net> > Cc: George Dunlap <George.Dunlap@citrix.com>; xen- > devel@lists.xenproject.org > 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? Paul _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PCI Device Subtree Change from Traditional to Upstream 2018-01-04 13:26 ` Paul Durrant @ 2018-01-04 21:17 ` Kevin Stange 2018-01-05 9:03 ` Paul Durrant 0 siblings, 1 reply; 20+ messages in thread From: Kevin Stange @ 2018-01-04 21:17 UTC (permalink / raw) To: Paul Durrant Cc: Anthony Perard, xen-devel@lists.xenproject.org, George Dunlap On 01/04/2018 07:26 AM, Paul Durrant wrote: >> -----Original Message----- >> From: Xen-devel [mailto:xen-devel-bounces@lists.xenproject.org] On Behalf >> Of Anthony PERARD >> Sent: 04 January 2018 12:52 >> To: Kevin Stange <kevin@steadfast.net> >> Cc: George Dunlap <George.Dunlap@citrix.com>; xen- >> devel@lists.xenproject.org >> 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. -- 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@steadfast.net | www.steadfast.net _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PCI Device Subtree Change from Traditional to Upstream 2018-01-04 21:17 ` Kevin Stange @ 2018-01-05 9:03 ` Paul Durrant 2018-01-05 17:05 ` Kevin Stange 0 siblings, 1 reply; 20+ messages in thread From: Paul Durrant @ 2018-01-05 9:03 UTC (permalink / raw) To: 'Kevin Stange' Cc: Anthony Perard, xen-devel@lists.xenproject.org, George Dunlap > -----Original Message----- > From: Kevin Stange [mailto:kevin@steadfast.net] > Sent: 04 January 2018 21:17 > To: Paul Durrant <Paul.Durrant@citrix.com> > Cc: George Dunlap <George.Dunlap@citrix.com>; xen- > devel@lists.xenproject.org; Anthony Perard <anthony.perard@citrix.com> > 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@lists.xenproject.org] On > Behalf > >> Of Anthony PERARD > >> Sent: 04 January 2018 12:52 > >> To: Kevin Stange <kevin@steadfast.net> > >> Cc: George Dunlap <George.Dunlap@citrix.com>; xen- > >> devel@lists.xenproject.org > >> 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@steadfast.net | www.steadfast.net _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PCI Device Subtree Change from Traditional to Upstream 2018-01-05 9:03 ` Paul Durrant @ 2018-01-05 17:05 ` Kevin Stange 0 siblings, 0 replies; 20+ messages in thread From: Kevin Stange @ 2018-01-05 17:05 UTC (permalink / raw) To: Paul Durrant Cc: Anthony Perard, xen-devel@lists.xenproject.org, George Dunlap On 01/05/2018 03:03 AM, Paul Durrant wrote: >> -----Original Message----- >> From: Kevin Stange [mailto:kevin@steadfast.net] >> Sent: 04 January 2018 21:17 >> To: Paul Durrant <Paul.Durrant@citrix.com> >> Cc: George Dunlap <George.Dunlap@citrix.com>; xen- >> devel@lists.xenproject.org; Anthony Perard <anthony.perard@citrix.com> >> 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@lists.xenproject.org] On >> Behalf >>>> Of Anthony PERARD >>>> Sent: 04 January 2018 12:52 >>>> To: Kevin Stange <kevin@steadfast.net> >>>> Cc: George Dunlap <George.Dunlap@citrix.com>; xen- >>>> devel@lists.xenproject.org >>>> 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@steadfast.net | www.steadfast.net _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PCI Device Subtree Change from Traditional to Upstream 2018-01-04 12:52 ` Anthony PERARD 2018-01-04 13:26 ` Paul Durrant @ 2018-01-04 21:16 ` Kevin Stange 2018-01-05 17:10 ` Kevin Stange 2018-01-25 17:54 ` George Dunlap 2 siblings, 1 reply; 20+ messages in thread From: Kevin Stange @ 2018-01-04 21:16 UTC (permalink / raw) To: Anthony PERARD; +Cc: George Dunlap, xen-devel On 01/04/2018 06:52 AM, Anthony PERARD wrote: > 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. >>> >>> Hi Kevin, >>> >>> I've got a patch to QEMU that seems to do the trick: >>> >>> From: Anthony PERARD <anthony.perard@citrix.com> >>> Subject: [PATCH] xen-platform: Hardcode PCI slot to 3 >>> >>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> >>> --- >>> hw/i386/pc_piix.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c >>> index 5e47528993..93e3a9a916 100644 >>> --- a/hw/i386/pc_piix.c >>> +++ b/hw/i386/pc_piix.c >>> @@ -405,7 +405,7 @@ static void pc_xen_hvm_init(MachineState *machine) >>> >>> bus = pci_find_primary_bus(); >>> if (bus != NULL) { >>> - pci_create_simple(bus, -1, "xen-platform"); >>> + pci_create_simple(bus, PCI_DEVFN(3, 0), "xen-platform"); >>> } >>> } >>> #endif >>> >>> >>> The same thing could be done by libxl, by providing specific command >>> line options to qemu. (I think that could even be done via a different >>> config file for the guest.) >> >> This patch doesn't seem to work for me. It seems like the device model >> process is exiting immediately, but I haven't been able to find any >> information as to what is going wrong. I tested with Xen 4.6.6 and the >> QEMU packaged with that release. Should I try it on a different version >> of Xen and QEMU? > > What this patch does is asking QEMU to insert the PCI card > "xen-platform" into the 3rd PCI slot. My guess is that failed because > there is already a PCI device there. > > You could check qemu's logs, it's in > /var/log/xen/qemu-dm-${guest_name}.log The log file in question only says: qemu: terminating on signal 1 from pid 8865 > Let's try something else, instead of patching QEMU, we can patch libxl, > that might work better. Can you try this patch? (I've only test > compiled.) I've write the patch for Xen 4.6, since that the version you > are using. This isn't doing the trick either, with the same misbehavior. The log file is the same in both cases. -- 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@steadfast.net | www.steadfast.net _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PCI Device Subtree Change from Traditional to Upstream 2018-01-04 21:16 ` Kevin Stange @ 2018-01-05 17:10 ` Kevin Stange 2018-01-05 20:56 ` Kevin Stange 0 siblings, 1 reply; 20+ messages in thread From: Kevin Stange @ 2018-01-05 17:10 UTC (permalink / raw) To: Anthony PERARD; +Cc: George Dunlap, xen-devel On 01/04/2018 03:16 PM, Kevin Stange wrote: > On 01/04/2018 06:52 AM, Anthony PERARD wrote: >> 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. >>>> >>>> Hi Kevin, >>>> >>>> I've got a patch to QEMU that seems to do the trick: >>>> >>>> From: Anthony PERARD <anthony.perard@citrix.com> >>>> Subject: [PATCH] xen-platform: Hardcode PCI slot to 3 >>>> >>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> >>>> --- >>>> hw/i386/pc_piix.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c >>>> index 5e47528993..93e3a9a916 100644 >>>> --- a/hw/i386/pc_piix.c >>>> +++ b/hw/i386/pc_piix.c >>>> @@ -405,7 +405,7 @@ static void pc_xen_hvm_init(MachineState *machine) >>>> >>>> bus = pci_find_primary_bus(); >>>> if (bus != NULL) { >>>> - pci_create_simple(bus, -1, "xen-platform"); >>>> + pci_create_simple(bus, PCI_DEVFN(3, 0), "xen-platform"); >>>> } >>>> } >>>> #endif >>>> >>>> >>>> The same thing could be done by libxl, by providing specific command >>>> line options to qemu. (I think that could even be done via a different >>>> config file for the guest.) >>> >>> This patch doesn't seem to work for me. It seems like the device model >>> process is exiting immediately, but I haven't been able to find any >>> information as to what is going wrong. I tested with Xen 4.6.6 and the >>> QEMU packaged with that release. Should I try it on a different version >>> of Xen and QEMU? >> >> What this patch does is asking QEMU to insert the PCI card >> "xen-platform" into the 3rd PCI slot. My guess is that failed because >> there is already a PCI device there. >> >> You could check qemu's logs, it's in >> /var/log/xen/qemu-dm-${guest_name}.log > > The log file in question only says: > > qemu: terminating on signal 1 from pid 8865 > >> Let's try something else, instead of patching QEMU, we can patch libxl, >> that might work better. Can you try this patch? (I've only test >> compiled.) I've write the patch for Xen 4.6, since that the version you >> are using. > > This isn't doing the trick either, with the same misbehavior. The log > file is the same in both cases. I'm getting confusing behavior here. I tried to boot a guest using a build with the second patch and behaves the way the first one did, with the qemu-system-i386 process exiting and preventing the guest from ever booting. However, I tried to downgrade the packages to completely unpatched version in preparation to reboot again and once the older copy of the runtime is installed, the qemu-system-i386 starts properly using the command line arguments that libxl had specified and the system comes up with the correct PCI subtree. This leads me to believe something about my build is screwed up somehow such that my qemu-system-i386 is broken. I'm quite sure I'm not applying any extra patches to it that weren't otherwise in the CentOS virt packages. -- 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@steadfast.net | www.steadfast.net _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PCI Device Subtree Change from Traditional to Upstream 2018-01-05 17:10 ` Kevin Stange @ 2018-01-05 20:56 ` Kevin Stange 0 siblings, 0 replies; 20+ messages in thread From: Kevin Stange @ 2018-01-05 20:56 UTC (permalink / raw) To: Anthony PERARD; +Cc: George Dunlap, xen-devel On 01/05/2018 11:10 AM, Kevin Stange wrote: > On 01/04/2018 03:16 PM, Kevin Stange wrote: >> On 01/04/2018 06:52 AM, Anthony PERARD wrote: >>> 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. >>>>> >>>>> Hi Kevin, >>>>> >>>>> I've got a patch to QEMU that seems to do the trick: >>>>> >>>>> From: Anthony PERARD <anthony.perard@citrix.com> >>>>> Subject: [PATCH] xen-platform: Hardcode PCI slot to 3 >>>>> >>>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> >>>>> --- >>>>> hw/i386/pc_piix.c | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c >>>>> index 5e47528993..93e3a9a916 100644 >>>>> --- a/hw/i386/pc_piix.c >>>>> +++ b/hw/i386/pc_piix.c >>>>> @@ -405,7 +405,7 @@ static void pc_xen_hvm_init(MachineState *machine) >>>>> >>>>> bus = pci_find_primary_bus(); >>>>> if (bus != NULL) { >>>>> - pci_create_simple(bus, -1, "xen-platform"); >>>>> + pci_create_simple(bus, PCI_DEVFN(3, 0), "xen-platform"); >>>>> } >>>>> } >>>>> #endif >>>>> >>>>> >>>>> The same thing could be done by libxl, by providing specific command >>>>> line options to qemu. (I think that could even be done via a different >>>>> config file for the guest.) >>>> >>>> This patch doesn't seem to work for me. It seems like the device model >>>> process is exiting immediately, but I haven't been able to find any >>>> information as to what is going wrong. I tested with Xen 4.6.6 and the >>>> QEMU packaged with that release. Should I try it on a different version >>>> of Xen and QEMU? >>> >>> What this patch does is asking QEMU to insert the PCI card >>> "xen-platform" into the 3rd PCI slot. My guess is that failed because >>> there is already a PCI device there. >>> >>> You could check qemu's logs, it's in >>> /var/log/xen/qemu-dm-${guest_name}.log >> >> The log file in question only says: >> >> qemu: terminating on signal 1 from pid 8865 >> >>> Let's try something else, instead of patching QEMU, we can patch libxl, >>> that might work better. Can you try this patch? (I've only test >>> compiled.) I've write the patch for Xen 4.6, since that the version you >>> are using. >> >> This isn't doing the trick either, with the same misbehavior. The log >> file is the same in both cases. > > I'm getting confusing behavior here. I tried to boot a guest using a > build with the second patch and behaves the way the first one did, with > the qemu-system-i386 process exiting and preventing the guest from ever > booting. However, I tried to downgrade the packages to completely > unpatched version in preparation to reboot again and once the older copy > of the runtime is installed, the qemu-system-i386 starts properly using > the command line arguments that libxl had specified and the system comes > up with the correct PCI subtree. > > This leads me to believe something about my build is screwed up somehow > such that my qemu-system-i386 is broken. I'm quite sure I'm not > applying any extra patches to it that weren't otherwise in the CentOS > virt packages. George pointed me at the fact I had failed to pull in the seabios package from CentOS virt. The version from RHEL is broken and that was my issue. Sorry for generating extra noise as a result. I can confirm that patch 2 (and probably patch 1, really) work around the issue for me. Thank you for the help! It would be nice if there was a way to set default or override options to domains from a configuration file that is read by libxl, qemu, or libvirt but I see no code or documentation to support that right now. -- 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@steadfast.net | www.steadfast.net _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PCI Device Subtree Change from Traditional to Upstream 2018-01-04 12:52 ` Anthony PERARD 2018-01-04 13:26 ` Paul Durrant 2018-01-04 21:16 ` Kevin Stange @ 2018-01-25 17:54 ` George Dunlap 2018-01-25 18:04 ` Anthony PERARD 2 siblings, 1 reply; 20+ messages in thread From: George Dunlap @ 2018-01-25 17:54 UTC (permalink / raw) To: Anthony PERARD, Kevin Stange; +Cc: George Dunlap, xen-devel On 01/04/2018 12:52 PM, Anthony PERARD wrote: > 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. >>> >>> Hi Kevin, >>> >>> I've got a patch to QEMU that seems to do the trick: >>> >>> From: Anthony PERARD <anthony.perard@citrix.com> >>> Subject: [PATCH] xen-platform: Hardcode PCI slot to 3 >>> >>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> >>> --- >>> hw/i386/pc_piix.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c >>> index 5e47528993..93e3a9a916 100644 >>> --- a/hw/i386/pc_piix.c >>> +++ b/hw/i386/pc_piix.c >>> @@ -405,7 +405,7 @@ static void pc_xen_hvm_init(MachineState *machine) >>> >>> bus = pci_find_primary_bus(); >>> if (bus != NULL) { >>> - pci_create_simple(bus, -1, "xen-platform"); >>> + pci_create_simple(bus, PCI_DEVFN(3, 0), "xen-platform"); >>> } >>> } >>> #endif >>> >>> >>> The same thing could be done by libxl, by providing specific command >>> line options to qemu. (I think that could even be done via a different >>> config file for the guest.) >> >> This patch doesn't seem to work for me. It seems like the device model >> process is exiting immediately, but I haven't been able to find any >> information as to what is going wrong. I tested with Xen 4.6.6 and the >> QEMU packaged with that release. Should I try it on a different version >> of Xen and QEMU? > > What this patch does is asking QEMU to insert the PCI card > "xen-platform" into the 3rd PCI slot. My guess is that failed because > there is already a PCI device there. > > You could check qemu's logs, it's in > /var/log/xen/qemu-dm-${guest_name}.log > > > Let's try something else, instead of patching QEMU, we can patch libxl, > that might work better. Can you try this patch? (I've only test > compiled.) I've write the patch for Xen 4.6, since that the version you > are using. > > > From: Anthony PERARD <anthony.perard@citrix.com> > Subject: [PATCH] libxl_dm: Explicitly put xen-platform device on PCI slot 3 > > In order to do that, we don't use xenfv machine anymore and explicity > add the platform device on the command line. > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Anthony, It seems like we might want to add the ability to specify which slot we want the xen-platform device to occupy. Is it worth thinking of the best way to add a patch like this upstream? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PCI Device Subtree Change from Traditional to Upstream 2018-01-25 17:54 ` George Dunlap @ 2018-01-25 18:04 ` Anthony PERARD 2018-01-25 18:14 ` George Dunlap 0 siblings, 1 reply; 20+ messages in thread From: Anthony PERARD @ 2018-01-25 18:04 UTC (permalink / raw) To: George Dunlap; +Cc: Kevin Stange, xen-devel, George Dunlap On Thu, Jan 25, 2018 at 05:54:36PM +0000, George Dunlap wrote: > On 01/04/2018 12:52 PM, Anthony PERARD wrote: > > From: Anthony PERARD <anthony.perard@citrix.com> > > Subject: [PATCH] libxl_dm: Explicitly put xen-platform device on PCI slot 3 > > > > In order to do that, we don't use xenfv machine anymore and explicity > > add the platform device on the command line. > > > > Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> > > Anthony, > > It seems like we might want to add the ability to specify which slot we > want the xen-platform device to occupy. Is it worth thinking of the best > way to add a patch like this upstream? I think that would be nice for people who switch from qemu-trad to QEMU. The only question that remain is, how to name the xl config option? The rest is to simply take my libxl patch and make it use the new config option. -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PCI Device Subtree Change from Traditional to Upstream 2018-01-25 18:04 ` Anthony PERARD @ 2018-01-25 18:14 ` George Dunlap 2018-01-26 10:38 ` Paul Durrant 0 siblings, 1 reply; 20+ messages in thread From: George Dunlap @ 2018-01-25 18:14 UTC (permalink / raw) To: Anthony PERARD; +Cc: Kevin Stange, xen-devel, George Dunlap On 01/25/2018 06:04 PM, Anthony PERARD wrote: > On Thu, Jan 25, 2018 at 05:54:36PM +0000, George Dunlap wrote: >> On 01/04/2018 12:52 PM, Anthony PERARD wrote: >>> From: Anthony PERARD <anthony.perard@citrix.com> >>> Subject: [PATCH] libxl_dm: Explicitly put xen-platform device on PCI slot 3 >>> >>> In order to do that, we don't use xenfv machine anymore and explicity >>> add the platform device on the command line. >>> >>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> >> >> Anthony, >> >> It seems like we might want to add the ability to specify which slot we >> want the xen-platform device to occupy. Is it worth thinking of the best >> way to add a patch like this upstream? > > I think that would be nice for people who switch from qemu-trad to > QEMU. The only question that remain is, how to name the xl config > option? The rest is to simply take my libxl patch and make it use > the new config option. Well the other half would be to make sure something like this doesn't happen by accident in the future -- i.e., that no future changes in QEMU will accidentally move it away from whatever the current slot is now. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PCI Device Subtree Change from Traditional to Upstream 2018-01-25 18:14 ` George Dunlap @ 2018-01-26 10:38 ` Paul Durrant 2019-04-08 9:46 ` George Dunlap 0 siblings, 1 reply; 20+ messages in thread From: Paul Durrant @ 2018-01-26 10:38 UTC (permalink / raw) To: Anthony Perard Cc: Kevin Stange, xen-devel@lists.xenproject.org, George Dunlap > -----Original Message----- > From: Xen-devel [mailto:xen-devel-bounces@lists.xenproject.org] On Behalf > Of George Dunlap > Sent: 25 January 2018 18:15 > To: Anthony Perard <anthony.perard@citrix.com> > Cc: Kevin Stange <kevin@steadfast.net>; xen-devel@lists.xenproject.org; > George Dunlap <George.Dunlap@citrix.com> > Subject: Re: [Xen-devel] PCI Device Subtree Change from Traditional to > Upstream > > On 01/25/2018 06:04 PM, Anthony PERARD wrote: > > On Thu, Jan 25, 2018 at 05:54:36PM +0000, George Dunlap wrote: > >> On 01/04/2018 12:52 PM, Anthony PERARD wrote: > >>> From: Anthony PERARD <anthony.perard@citrix.com> > >>> Subject: [PATCH] libxl_dm: Explicitly put xen-platform device on PCI slot > 3 > >>> > >>> In order to do that, we don't use xenfv machine anymore and explicity > >>> add the platform device on the command line. > >>> > >>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> > >> > >> Anthony, > >> > >> It seems like we might want to add the ability to specify which slot we > >> want the xen-platform device to occupy. Is it worth thinking of the best > >> way to add a patch like this upstream? > > > > I think that would be nice for people who switch from qemu-trad to > > QEMU. The only question that remain is, how to name the xl config > > option? The rest is to simply take my libxl patch and make it use > > the new config option. > > Well the other half would be to make sure something like this doesn't > happen by accident in the future -- i.e., that no future changes in QEMU > will accidentally move it away from whatever the current slot is now. > IMO, it would be best if libxl specified the bus topology exactly (i.e. specified devfn for everything that appears on the bus). If we, as I hope, make a move to having Xen rather than QEMU own the topology then this should hopefully ensure at least some degree of forward compatibility. Paul > -George > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PCI Device Subtree Change from Traditional to Upstream 2018-01-26 10:38 ` Paul Durrant @ 2019-04-08 9:46 ` George Dunlap 2019-04-08 9:46 ` [Xen-devel] " George Dunlap 2019-04-08 9:51 ` Paul Durrant 0 siblings, 2 replies; 20+ messages in thread From: George Dunlap @ 2019-04-08 9:46 UTC (permalink / raw) To: Paul Durrant, Anthony Perard; +Cc: Kevin Stange, xen-devel@lists.xenproject.org On 1/26/18 10:38 AM, Paul Durrant wrote: >> -----Original Message----- >> From: Xen-devel [mailto:xen-devel-bounces@lists.xenproject.org] On Behalf >> Of George Dunlap >> Sent: 25 January 2018 18:15 >> To: Anthony Perard <anthony.perard@citrix.com> >> Cc: Kevin Stange <kevin@steadfast.net>; xen-devel@lists.xenproject.org; >> George Dunlap <George.Dunlap@citrix.com> >> Subject: Re: [Xen-devel] PCI Device Subtree Change from Traditional to >> Upstream >> >> On 01/25/2018 06:04 PM, Anthony PERARD wrote: >>> On Thu, Jan 25, 2018 at 05:54:36PM +0000, George Dunlap wrote: >>>> On 01/04/2018 12:52 PM, Anthony PERARD wrote: >>>>> From: Anthony PERARD <anthony.perard@citrix.com> >>>>> Subject: [PATCH] libxl_dm: Explicitly put xen-platform device on PCI slot >> 3 >>>>> >>>>> In order to do that, we don't use xenfv machine anymore and explicity >>>>> add the platform device on the command line. >>>>> >>>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> >>>> >>>> Anthony, >>>> >>>> It seems like we might want to add the ability to specify which slot we >>>> want the xen-platform device to occupy. Is it worth thinking of the best >>>> way to add a patch like this upstream? >>> >>> I think that would be nice for people who switch from qemu-trad to >>> QEMU. The only question that remain is, how to name the xl config >>> option? The rest is to simply take my libxl patch and make it use >>> the new config option. >> >> Well the other half would be to make sure something like this doesn't >> happen by accident in the future -- i.e., that no future changes in QEMU >> will accidentally move it away from whatever the current slot is now. >> > > IMO, it would be best if libxl specified the bus topology exactly (i.e. specified devfn for everything that appears on the bus). If we, as I hope, make a move to having Xen rather than QEMU own the topology then this should hopefully ensure at least some degree of forward compatibility. Is this on anybody's radar? It seems like this wouldn't be a huge amount of work, and it would prevent this sort of compatibility issue in the future. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream 2019-04-08 9:46 ` George Dunlap @ 2019-04-08 9:46 ` George Dunlap 2019-04-08 9:51 ` Paul Durrant 1 sibling, 0 replies; 20+ messages in thread From: George Dunlap @ 2019-04-08 9:46 UTC (permalink / raw) To: Paul Durrant, Anthony Perard; +Cc: Kevin Stange, xen-devel@lists.xenproject.org On 1/26/18 10:38 AM, Paul Durrant wrote: >> -----Original Message----- >> From: Xen-devel [mailto:xen-devel-bounces@lists.xenproject.org] On Behalf >> Of George Dunlap >> Sent: 25 January 2018 18:15 >> To: Anthony Perard <anthony.perard@citrix.com> >> Cc: Kevin Stange <kevin@steadfast.net>; xen-devel@lists.xenproject.org; >> George Dunlap <George.Dunlap@citrix.com> >> Subject: Re: [Xen-devel] PCI Device Subtree Change from Traditional to >> Upstream >> >> On 01/25/2018 06:04 PM, Anthony PERARD wrote: >>> On Thu, Jan 25, 2018 at 05:54:36PM +0000, George Dunlap wrote: >>>> On 01/04/2018 12:52 PM, Anthony PERARD wrote: >>>>> From: Anthony PERARD <anthony.perard@citrix.com> >>>>> Subject: [PATCH] libxl_dm: Explicitly put xen-platform device on PCI slot >> 3 >>>>> >>>>> In order to do that, we don't use xenfv machine anymore and explicity >>>>> add the platform device on the command line. >>>>> >>>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> >>>> >>>> Anthony, >>>> >>>> It seems like we might want to add the ability to specify which slot we >>>> want the xen-platform device to occupy. Is it worth thinking of the best >>>> way to add a patch like this upstream? >>> >>> I think that would be nice for people who switch from qemu-trad to >>> QEMU. The only question that remain is, how to name the xl config >>> option? The rest is to simply take my libxl patch and make it use >>> the new config option. >> >> Well the other half would be to make sure something like this doesn't >> happen by accident in the future -- i.e., that no future changes in QEMU >> will accidentally move it away from whatever the current slot is now. >> > > IMO, it would be best if libxl specified the bus topology exactly (i.e. specified devfn for everything that appears on the bus). If we, as I hope, make a move to having Xen rather than QEMU own the topology then this should hopefully ensure at least some degree of forward compatibility. Is this on anybody's radar? It seems like this wouldn't be a huge amount of work, and it would prevent this sort of compatibility issue in the future. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: PCI Device Subtree Change from Traditional to Upstream 2019-04-08 9:46 ` George Dunlap 2019-04-08 9:46 ` [Xen-devel] " George Dunlap @ 2019-04-08 9:51 ` Paul Durrant 2019-04-08 9:51 ` [Xen-devel] " Paul Durrant 1 sibling, 1 reply; 20+ messages in thread From: Paul Durrant @ 2019-04-08 9:51 UTC (permalink / raw) To: George Dunlap, Anthony Perard Cc: Kevin Stange, xen-devel@lists.xenproject.org > -----Original Message----- > From: George Dunlap [mailto:george.dunlap@citrix.com] > Sent: 08 April 2019 10:47 > To: Paul Durrant <Paul.Durrant@citrix.com>; Anthony Perard <anthony.perard@citrix.com> > Cc: Kevin Stange <kevin@steadfast.net>; xen-devel@lists.xenproject.org > Subject: Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream > > On 1/26/18 10:38 AM, Paul Durrant wrote: > >> -----Original Message----- > >> From: Xen-devel [mailto:xen-devel-bounces@lists.xenproject.org] On Behalf > >> Of George Dunlap > >> Sent: 25 January 2018 18:15 > >> To: Anthony Perard <anthony.perard@citrix.com> > >> Cc: Kevin Stange <kevin@steadfast.net>; xen-devel@lists.xenproject.org; > >> George Dunlap <George.Dunlap@citrix.com> > >> Subject: Re: [Xen-devel] PCI Device Subtree Change from Traditional to > >> Upstream > >> > >> On 01/25/2018 06:04 PM, Anthony PERARD wrote: > >>> On Thu, Jan 25, 2018 at 05:54:36PM +0000, George Dunlap wrote: > >>>> On 01/04/2018 12:52 PM, Anthony PERARD wrote: > >>>>> From: Anthony PERARD <anthony.perard@citrix.com> > >>>>> Subject: [PATCH] libxl_dm: Explicitly put xen-platform device on PCI slot > >> 3 > >>>>> > >>>>> In order to do that, we don't use xenfv machine anymore and explicity > >>>>> add the platform device on the command line. > >>>>> > >>>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> > >>>> > >>>> Anthony, > >>>> > >>>> It seems like we might want to add the ability to specify which slot we > >>>> want the xen-platform device to occupy. Is it worth thinking of the best > >>>> way to add a patch like this upstream? > >>> > >>> I think that would be nice for people who switch from qemu-trad to > >>> QEMU. The only question that remain is, how to name the xl config > >>> option? The rest is to simply take my libxl patch and make it use > >>> the new config option. > >> > >> Well the other half would be to make sure something like this doesn't > >> happen by accident in the future -- i.e., that no future changes in QEMU > >> will accidentally move it away from whatever the current slot is now. > >> > > > > IMO, it would be best if libxl specified the bus topology exactly (i.e. specified devfn for > everything that appears on the bus). If we, as I hope, make a move to having Xen rather than QEMU own > the topology then this should hopefully ensure at least some degree of forward compatibility. > > Is this on anybody's radar? It seems like this wouldn't be a huge > amount of work, and it would prevent this sort of compatibility issue in > the future. This very topic came up in relation to the XAPI toolstack last week. It would definitely be good to have commonality with libxl on this but I'm not aware of anyone working on this. Paul > > -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream 2019-04-08 9:51 ` Paul Durrant @ 2019-04-08 9:51 ` Paul Durrant 0 siblings, 0 replies; 20+ messages in thread From: Paul Durrant @ 2019-04-08 9:51 UTC (permalink / raw) To: George Dunlap, Anthony Perard Cc: Kevin Stange, xen-devel@lists.xenproject.org > -----Original Message----- > From: George Dunlap [mailto:george.dunlap@citrix.com] > Sent: 08 April 2019 10:47 > To: Paul Durrant <Paul.Durrant@citrix.com>; Anthony Perard <anthony.perard@citrix.com> > Cc: Kevin Stange <kevin@steadfast.net>; xen-devel@lists.xenproject.org > Subject: Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream > > On 1/26/18 10:38 AM, Paul Durrant wrote: > >> -----Original Message----- > >> From: Xen-devel [mailto:xen-devel-bounces@lists.xenproject.org] On Behalf > >> Of George Dunlap > >> Sent: 25 January 2018 18:15 > >> To: Anthony Perard <anthony.perard@citrix.com> > >> Cc: Kevin Stange <kevin@steadfast.net>; xen-devel@lists.xenproject.org; > >> George Dunlap <George.Dunlap@citrix.com> > >> Subject: Re: [Xen-devel] PCI Device Subtree Change from Traditional to > >> Upstream > >> > >> On 01/25/2018 06:04 PM, Anthony PERARD wrote: > >>> On Thu, Jan 25, 2018 at 05:54:36PM +0000, George Dunlap wrote: > >>>> On 01/04/2018 12:52 PM, Anthony PERARD wrote: > >>>>> From: Anthony PERARD <anthony.perard@citrix.com> > >>>>> Subject: [PATCH] libxl_dm: Explicitly put xen-platform device on PCI slot > >> 3 > >>>>> > >>>>> In order to do that, we don't use xenfv machine anymore and explicity > >>>>> add the platform device on the command line. > >>>>> > >>>>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> > >>>> > >>>> Anthony, > >>>> > >>>> It seems like we might want to add the ability to specify which slot we > >>>> want the xen-platform device to occupy. Is it worth thinking of the best > >>>> way to add a patch like this upstream? > >>> > >>> I think that would be nice for people who switch from qemu-trad to > >>> QEMU. The only question that remain is, how to name the xl config > >>> option? The rest is to simply take my libxl patch and make it use > >>> the new config option. > >> > >> Well the other half would be to make sure something like this doesn't > >> happen by accident in the future -- i.e., that no future changes in QEMU > >> will accidentally move it away from whatever the current slot is now. > >> > > > > IMO, it would be best if libxl specified the bus topology exactly (i.e. specified devfn for > everything that appears on the bus). If we, as I hope, make a move to having Xen rather than QEMU own > the topology then this should hopefully ensure at least some degree of forward compatibility. > > Is this on anybody's radar? It seems like this wouldn't be a huge > amount of work, and it would prevent this sort of compatibility issue in > the future. This very topic came up in relation to the XAPI toolstack last week. It would definitely be good to have commonality with libxl on this but I'm not aware of anyone working on this. Paul > > -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2019-04-08 9:52 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-12-20 17:40 PCI Device Subtree Change from Traditional to Upstream Kevin Stange 2017-12-20 17:44 ` George Dunlap 2018-01-03 17:57 ` Anthony PERARD 2018-01-03 23:10 ` Kevin Stange 2018-01-04 12:52 ` Anthony PERARD 2018-01-04 13:26 ` Paul Durrant 2018-01-04 21:17 ` Kevin Stange 2018-01-05 9:03 ` Paul Durrant 2018-01-05 17:05 ` Kevin Stange 2018-01-04 21:16 ` Kevin Stange 2018-01-05 17:10 ` Kevin Stange 2018-01-05 20:56 ` Kevin Stange 2018-01-25 17:54 ` George Dunlap 2018-01-25 18:04 ` Anthony PERARD 2018-01-25 18:14 ` George Dunlap 2018-01-26 10:38 ` Paul Durrant 2019-04-08 9:46 ` George Dunlap 2019-04-08 9:46 ` [Xen-devel] " George Dunlap 2019-04-08 9:51 ` Paul Durrant 2019-04-08 9:51 ` [Xen-devel] " Paul Durrant
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).