PCI Device Subtree Change from Traditional to Upstream

PCI Device Subtree Change from Traditional to Upstream

[Kevin Stange]

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

Re: PCI Device Subtree Change from Traditional to Upstream

[George Dunlap]

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

Re: PCI Device Subtree Change from Traditional to Upstream

[Anthony PERARD]

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

Re: PCI Device Subtree Change from Traditional to Upstream

[Kevin Stange]

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

Re: PCI Device Subtree Change from Traditional to Upstream

[Anthony PERARD]

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

Re: PCI Device Subtree Change from Traditional to Upstream

[Paul Durrant]

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

Re: PCI Device Subtree Change from Traditional to Upstream

[Kevin Stange]

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

Re: PCI Device Subtree Change from Traditional to Upstream

[Kevin Stange]

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

Re: PCI Device Subtree Change from Traditional to Upstream

[Paul Durrant]

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

Re: PCI Device Subtree Change from Traditional to Upstream

[Kevin Stange]

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

Re: PCI Device Subtree Change from Traditional to Upstream

[Kevin Stange]

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

Re: PCI Device Subtree Change from Traditional to Upstream

[Kevin Stange]

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

Re: PCI Device Subtree Change from Traditional to Upstream

[George Dunlap]

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

Re: PCI Device Subtree Change from Traditional to Upstream

[Anthony PERARD]

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

Re: PCI Device Subtree Change from Traditional to Upstream

[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

Re: PCI Device Subtree Change from Traditional to Upstream

[Paul Durrant]

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

Re: PCI Device Subtree Change from Traditional to Upstream

[George Dunlap]

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

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

[George Dunlap]

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

Re: PCI Device Subtree Change from Traditional to Upstream

[Paul Durrant]

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

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

[Paul Durrant]

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