Multiple platform PCI device ID registries?

Multiple platform PCI device ID registries?

[Ian Campbell]

http://xenbits.xen.org/docs/unstable-staging/misc/pci-device-reservations.txt
vs
http://xenbits.xen.org/docs/unstable-staging/hypercall/x86_64/include,public,hvm,pvdrivers.h.html

Are they distinct namespaces? Can someone clarify with a patch to one or
both what the relationship is? How does this relate to the additional
platform device thing which Paul added to qemu?

I'm particularly concerned that 0x0002 is different in the two of
them...

Ian.

Re: Multiple platform PCI device ID registries?

[Paul Durrant]

> -----Original Message-----
> From: Ian Campbell
> Sent: 13 November 2013 09:41
> To: xen-devel
> Cc: Paul Durrant; Ian Jackson; Stefano Stabellini
> Subject: Multiple platform PCI device ID registries?
> 
> http://xenbits.xen.org/docs/unstable-staging/misc/pci-device-
> reservations.txt
> vs
> http://xenbits.xen.org/docs/unstable-
> staging/hypercall/x86_64/include,public,hvm,pvdrivers.h.html
> 
> Are they distinct namespaces? Can someone clarify with a patch to one or
> both what the relationship is? How does this relate to the additional
> platform device thing which Paul added to qemu?
> 
> I'm particularly concerned that 0x0002 is different in the two of
> them...
> 

They are distinct namespaces. The former is PCI device ID, the latter is an abstract 'product number' which is used as part of the QEMU unplug protocol (and actually means nothing to the upstream QEMU platform device code anyway).

  Paul

Re: Multiple platform PCI device ID registries?

[Ian Campbell]

On Wed, 2013-11-13 at 11:01 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 13 November 2013 09:41
> > To: xen-devel
> > Cc: Paul Durrant; Ian Jackson; Stefano Stabellini
> > Subject: Multiple platform PCI device ID registries?
> > 
> > http://xenbits.xen.org/docs/unstable-staging/misc/pci-device-
> > reservations.txt
> > vs
> > http://xenbits.xen.org/docs/unstable-
> > staging/hypercall/x86_64/include,public,hvm,pvdrivers.h.html
> > 
> > Are they distinct namespaces? Can someone clarify with a patch to one or
> > both what the relationship is? How does this relate to the additional
> > platform device thing which Paul added to qemu?
> > 
> > I'm particularly concerned that 0x0002 is different in the two of
> > them...
> > 
> 
> They are distinct namespaces. The former is PCI device ID, the latter
> is an abstract 'product number' which is used as part of the QEMU
> unplug protocol (and actually means nothing to the upstream QEMU
> platform device code anyway).

I'm confused then. qemu.git:
        commit 8fbab3b62a271526c782110aed0ae160eb38c296
        Author: Paul Durrant <paul.durrant@citrix.com>
        Date:   Mon Jul 29 10:58:01 2013 +0000
        
            Xen PV Device
            
            Introduces a new Xen PV PCI device which will act as a binding point for
            PV drivers for Xen.
            The device has parameterized vendor-id, device-id and revision to allow to
            be configured as a binding point for any vendor's PV drivers.
            
            Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
            Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
            Reviewed-by: Andreas Färber <afaerber@suse.de>
        
Adds a new device with parameterized vendor and device-id, which sounds
like a pci-device-reservations.txt thing. But you reserved entries in
the pvdrivers.h list which is a "product number" thing? Maybe I'm
confusing two different events?

That patch uses device ID
#define PCI_DEVICE_ID_XEN_PVDEVICE       0x0002

which appears to conflict with pci-device-reservations.txt which says
that devid 2 is "Citrix XenServer (grandfathered allocation for
XenServer 6.1)" Or maybe the comment there is just out of date?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Multiple platform PCI device ID registries?

[Ian Campbell]

On Wed, 2013-11-13 at 11:24 +0000, Ian Campbell wrote:
> On Wed, 2013-11-13 at 11:01 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 13 November 2013 09:41
> > > To: xen-devel
> > > Cc: Paul Durrant; Ian Jackson; Stefano Stabellini
> > > Subject: Multiple platform PCI device ID registries?
> > > 
> > > http://xenbits.xen.org/docs/unstable-staging/misc/pci-device-
> > > reservations.txt
> > > vs
> > > http://xenbits.xen.org/docs/unstable-
> > > staging/hypercall/x86_64/include,public,hvm,pvdrivers.h.html
> > > 
> > > Are they distinct namespaces? Can someone clarify with a patch to one or
> > > both what the relationship is? How does this relate to the additional
> > > platform device thing which Paul added to qemu?
> > > 
> > > I'm particularly concerned that 0x0002 is different in the two of
> > > them...
> > > 
> > 
> > They are distinct namespaces. The former is PCI device ID, the latter
> > is an abstract 'product number' which is used as part of the QEMU
> > unplug protocol (and actually means nothing to the upstream QEMU
> > platform device code anyway).
> 
> I'm confused then.

And hence the following is as far as I got writing this down:

commit 8d34df2602ee99cc2efde160d3f297afdcaa80f7
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Wed Nov 13 11:31:16 2013 +0000

    docs: clarify PV driver product numbers and PCI device ids
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/docs/misc/hvm-emulated-unplug.markdown b/docs/misc/hvm-emulated-unplug.markdown
index ec9ce83..d0e4af8 100644
--- a/docs/misc/hvm-emulated-unplug.markdown
+++ b/docs/misc/hvm-emulated-unplug.markdown
@@ -21,9 +21,8 @@ drivers):
 2. The drivers read a one-byte protocol version from IO port `0x12`.  If
    this is 0, skip to 6.
 
-3. The drivers write a two-byte product number to IO port `0x12`.  At
-   the moment, the only drivers using this protocol are our
-   closed-source ones, which use product number 1.
+3. The drivers write a two-byte product number to IO port `0x12`.  The
+   product number registry is http://xenbits.xen.org/docs/unstable-staging/hypercall/x86_64/include,public,hvm,pvdrivers.h.html#incontents_pvdrivers.
 
 4. The drivers write a four-byte build number to IO port `0x10`.
 
diff --git a/docs/misc/pci-device-reservations.txt b/docs/misc/pci-device-reservations.txt
index 19bd9d5..e98b848 100644
--- a/docs/misc/pci-device-reservations.txt
+++ b/docs/misc/pci-device-reservations.txt
@@ -29,3 +29,10 @@ Reservations
 0x0002        | Citrix XenServer (grandfathered allocation for XenServer 6.1)
 0xc000-0xc0ff | Citrix XenServer
 0xc100-0xc1ff | Citrix XenClient
+
+Product Vendor IDs
+==================
+
+Note that this namespace is distinct to the product number used in
+`hvm-emulated-unplug` and enumerated in
+http://xenbits.xen.org/docs/unstable-staging/hypercall/x86_64/include,public,hvm,pvdrivers.h.html#incontents_pvdrivers.
diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h
index 4c6b705..94fca57 100644
--- a/xen/include/public/hvm/pvdrivers.h
+++ b/xen/include/public/hvm/pvdrivers.h
@@ -25,11 +25,15 @@
 #define _XEN_PUBLIC_PVDRIVERS_H_
 
 /*
+ * `incontents 300 pvdrivers PV Driver Product Numbers
+ *
  * This is the master registry of product numbers for
- * PV drivers. 
+ * PV drivers.
+ *
  * If you need a new product number allocating, please
- * post to xen-devel@lists.xensource.com.  You should NOT use
+ * post to xen-devel@lists.xenproject.org.  You should NOT use
  * a product number without allocating one.
+ *
  * If you maintain a separate versioning and distribution path
  * for PV drivers you should have a separate product number so
  * that your drivers can be separated from others.

Re: Multiple platform PCI device ID registries?

[Paul Durrant]

> -----Original Message-----
> From: Ian Campbell
> Sent: 13 November 2013 11:25
> To: Paul Durrant
> Cc: xen-devel; Ian Jackson; Stefano Stabellini
> Subject: Re: Multiple platform PCI device ID registries?
> 
> On Wed, 2013-11-13 at 11:01 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 13 November 2013 09:41
> > > To: xen-devel
> > > Cc: Paul Durrant; Ian Jackson; Stefano Stabellini
> > > Subject: Multiple platform PCI device ID registries?
> > >
> > > http://xenbits.xen.org/docs/unstable-staging/misc/pci-device-
> > > reservations.txt
> > > vs
> > > http://xenbits.xen.org/docs/unstable-
> > > staging/hypercall/x86_64/include,public,hvm,pvdrivers.h.html
> > >
> > > Are they distinct namespaces? Can someone clarify with a patch to one or
> > > both what the relationship is? How does this relate to the additional
> > > platform device thing which Paul added to qemu?
> > >
> > > I'm particularly concerned that 0x0002 is different in the two of
> > > them...
> > >
> >
> > They are distinct namespaces. The former is PCI device ID, the latter
> > is an abstract 'product number' which is used as part of the QEMU
> > unplug protocol (and actually means nothing to the upstream QEMU
> > platform device code anyway).
> 
> I'm confused then. qemu.git:
>         commit 8fbab3b62a271526c782110aed0ae160eb38c296
>         Author: Paul Durrant <paul.durrant@citrix.com>
>         Date:   Mon Jul 29 10:58:01 2013 +0000
> 
>             Xen PV Device
> 
>             Introduces a new Xen PV PCI device which will act as a binding point for
>             PV drivers for Xen.
>             The device has parameterized vendor-id, device-id and revision to
> allow to
>             be configured as a binding point for any vendor's PV drivers.
> 
>             Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>             Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>             Reviewed-by: Andreas Färber <afaerber@suse.de>
> 
> Adds a new device with parameterized vendor and device-id, which sounds
> like a pci-device-reservations.txt thing. But you reserved entries in
> the pvdrivers.h list which is a "product number" thing? Maybe I'm
> confusing two different events?
> 

Yes, they are completely distinct things. Not related in the slightest.

The former was to add a parameterized device which we can use to hang PV drivers off for Windows Update purposes.
The latter was add reservations for a product numbers that is already in use in XenServer, and another one which we will use going forward that - by reserving it - should now not conflict with anyone else's PV drivers in future (if anyone cares to add product-number-based blacklisting into upstream QEMU or amend the code in trad.)

> That patch uses device ID
> #define PCI_DEVICE_ID_XEN_PVDEVICE       0x0002
> 
> which appears to conflict with pci-device-reservations.txt which says
> that devid 2 is "Citrix XenServer (grandfathered allocation for
> XenServer 6.1)" Or maybe the comment there is just out of date?
> 

Using 2 seems safe as it doesn't conflict with the platform device ID and we have now registered that ID. In practice it should never be used as the device ID should always be specified by the toolstack.

  Paul

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Multiple platform PCI device ID registries?

[Paul Durrant]

> -----Original Message-----
> From: Ian Campbell
> Sent: 13 November 2013 11:33
> To: Paul Durrant
> Cc: xen-devel; Ian Jackson; Stefano Stabellini
> Subject: Re: Multiple platform PCI device ID registries?
> 
> On Wed, 2013-11-13 at 11:24 +0000, Ian Campbell wrote:
> > On Wed, 2013-11-13 at 11:01 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > Sent: 13 November 2013 09:41
> > > > To: xen-devel
> > > > Cc: Paul Durrant; Ian Jackson; Stefano Stabellini
> > > > Subject: Multiple platform PCI device ID registries?
> > > >
> > > > http://xenbits.xen.org/docs/unstable-staging/misc/pci-device-
> > > > reservations.txt
> > > > vs
> > > > http://xenbits.xen.org/docs/unstable-
> > > > staging/hypercall/x86_64/include,public,hvm,pvdrivers.h.html
> > > >
> > > > Are they distinct namespaces? Can someone clarify with a patch to one
> or
> > > > both what the relationship is? How does this relate to the additional
> > > > platform device thing which Paul added to qemu?
> > > >
> > > > I'm particularly concerned that 0x0002 is different in the two of
> > > > them...
> > > >
> > >
> > > They are distinct namespaces. The former is PCI device ID, the latter
> > > is an abstract 'product number' which is used as part of the QEMU
> > > unplug protocol (and actually means nothing to the upstream QEMU
> > > platform device code anyway).
> >
> > I'm confused then.
> 
> And hence the following is as far as I got writing this down:
> 
> commit 8d34df2602ee99cc2efde160d3f297afdcaa80f7
> Author: Ian Campbell <ian.campbell@citrix.com>
> Date:   Wed Nov 13 11:31:16 2013 +0000
> 
>     docs: clarify PV driver product numbers and PCI device ids
> 
>     Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff --git a/docs/misc/hvm-emulated-unplug.markdown b/docs/misc/hvm-
> emulated-unplug.markdown
> index ec9ce83..d0e4af8 100644
> --- a/docs/misc/hvm-emulated-unplug.markdown
> +++ b/docs/misc/hvm-emulated-unplug.markdown
> @@ -21,9 +21,8 @@ drivers):
>  2. The drivers read a one-byte protocol version from IO port `0x12`.  If
>     this is 0, skip to 6.
> 
> -3. The drivers write a two-byte product number to IO port `0x12`.  At
> -   the moment, the only drivers using this protocol are our
> -   closed-source ones, which use product number 1.
> +3. The drivers write a two-byte product number to IO port `0x12`.  The
> +   product number registry is http://xenbits.xen.org/docs/unstable-
> staging/hypercall/x86_64/include,public,hvm,pvdrivers.h.html#incontents_p
> vdrivers.
> 
>  4. The drivers write a four-byte build number to IO port `0x10`.
> 
> diff --git a/docs/misc/pci-device-reservations.txt b/docs/misc/pci-device-
> reservations.txt
> index 19bd9d5..e98b848 100644
> --- a/docs/misc/pci-device-reservations.txt
> +++ b/docs/misc/pci-device-reservations.txt
> @@ -29,3 +29,10 @@ Reservations
>  0x0002        | Citrix XenServer (grandfathered allocation for XenServer 6.1)
>  0xc000-0xc0ff | Citrix XenServer
>  0xc100-0xc1ff | Citrix XenClient
> +
> +Product Vendor IDs
> +==================
> +
> +Note that this namespace is distinct to the product number used in
> +`hvm-emulated-unplug` and enumerated in
> +http://xenbits.xen.org/docs/unstable-
> staging/hypercall/x86_64/include,public,hvm,pvdrivers.h.html#incontents_p
> vdrivers.
> diff --git a/xen/include/public/hvm/pvdrivers.h
> b/xen/include/public/hvm/pvdrivers.h
> index 4c6b705..94fca57 100644
> --- a/xen/include/public/hvm/pvdrivers.h
> +++ b/xen/include/public/hvm/pvdrivers.h
> @@ -25,11 +25,15 @@
>  #define _XEN_PUBLIC_PVDRIVERS_H_
> 
>  /*
> + * `incontents 300 pvdrivers PV Driver Product Numbers
> + *
>   * This is the master registry of product numbers for
> - * PV drivers.
> + * PV drivers.
> + *
>   * If you need a new product number allocating, please
> - * post to xen-devel@lists.xensource.com.  You should NOT use
> + * post to xen-devel@lists.xenproject.org.  You should NOT use
>   * a product number without allocating one.
> + *
>   * If you maintain a separate versioning and distribution path
>   * for PV drivers you should have a separate product number so
>   * that your drivers can be separated from others.
> 

That looks good to me.

  Paul

Re: Multiple platform PCI device ID registries?

[Ian Campbell]

On Wed, 2013-11-13 at 11:33 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 13 November 2013 11:25
> > To: Paul Durrant
> > Cc: xen-devel; Ian Jackson; Stefano Stabellini
> > Subject: Re: Multiple platform PCI device ID registries?
> > 
> > On Wed, 2013-11-13 at 11:01 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > Sent: 13 November 2013 09:41
> > > > To: xen-devel
> > > > Cc: Paul Durrant; Ian Jackson; Stefano Stabellini
> > > > Subject: Multiple platform PCI device ID registries?
> > > >
> > > > http://xenbits.xen.org/docs/unstable-staging/misc/pci-device-
> > > > reservations.txt
> > > > vs
> > > > http://xenbits.xen.org/docs/unstable-
> > > > staging/hypercall/x86_64/include,public,hvm,pvdrivers.h.html
> > > >
> > > > Are they distinct namespaces? Can someone clarify with a patch to one or
> > > > both what the relationship is? How does this relate to the additional
> > > > platform device thing which Paul added to qemu?
> > > >
> > > > I'm particularly concerned that 0x0002 is different in the two of
> > > > them...
> > > >
> > >
> > > They are distinct namespaces. The former is PCI device ID, the latter
> > > is an abstract 'product number' which is used as part of the QEMU
> > > unplug protocol (and actually means nothing to the upstream QEMU
> > > platform device code anyway).
> > 
> > I'm confused then. qemu.git:
> >         commit 8fbab3b62a271526c782110aed0ae160eb38c296
> >         Author: Paul Durrant <paul.durrant@citrix.com>
> >         Date:   Mon Jul 29 10:58:01 2013 +0000
> > 
> >             Xen PV Device
> > 
> >             Introduces a new Xen PV PCI device which will act as a binding point for
> >             PV drivers for Xen.
> >             The device has parameterized vendor-id, device-id and revision to
> > allow to
> >             be configured as a binding point for any vendor's PV drivers.
> > 
> >             Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> >             Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >             Reviewed-by: Andreas Färber <afaerber@suse.de>
> > 
> > Adds a new device with parameterized vendor and device-id, which sounds
> > like a pci-device-reservations.txt thing. But you reserved entries in
> > the pvdrivers.h list which is a "product number" thing? Maybe I'm
> > confusing two different events?
> > 
> 
> Yes, they are completely distinct things. Not related in the slightest.

OK!

> The former was to add a parameterized device which we can use to hang
> PV drivers off for Windows Update purposes.
> The latter was add reservations for a product numbers that is already
> in use in XenServer, and another one which we will use going forward
> that - by reserving it - should now not conflict with anyone else's PV
> drivers in future (if anyone cares to add product-number-based
> blacklisting into upstream QEMU or amend the code in trad.)
> 
> > That patch uses device ID
> > #define PCI_DEVICE_ID_XEN_PVDEVICE       0x0002
> > 
> > which appears to conflict with pci-device-reservations.txt which says
> > that devid 2 is "Citrix XenServer (grandfathered allocation for
> > XenServer 6.1)" Or maybe the comment there is just out of date?
> > 
> 
> Using 2 seems safe as it doesn't conflict with the platform device ID
> and we have now registered that ID.

You are referring to the registration in pci-device-reservations.txt,
right?

I'm concerned because that comment refers to XenServer 6.1 but it now
appears to be being reused as the default device ID for the "Xen
pvdevice".

Maybe it is safe to reuse this in this way, but the docs should be
updated I think.

>  In practice it should never be used as the device ID should always be
> specified by the toolstack.

But it defaults to the Citrix ID -- is that wise? Wouldn't it be better
to default to nothing?

It also seems to be causing a moderate amount of fallout in the
"[Xen-devel] [BUG] Xen vm kernel crash in get_free_entries." thread.

I'm busy wondering if maybe Qemu should blacklist non-xenserver product
ids when it has been configured with the Xen PV device using the Citrix
devid?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Multiple platform PCI device ID registries?

[Paul Durrant]

> -----Original Message-----
> From: Ian Campbell
> Sent: 13 November 2013 11:44
> To: Paul Durrant
> Cc: xen-devel; Ian Jackson; Stefano Stabellini
> Subject: Re: Multiple platform PCI device ID registries?
> 
> On Wed, 2013-11-13 at 11:33 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 13 November 2013 11:25
> > > To: Paul Durrant
> > > Cc: xen-devel; Ian Jackson; Stefano Stabellini
> > > Subject: Re: Multiple platform PCI device ID registries?
> > >
> > > On Wed, 2013-11-13 at 11:01 +0000, Paul Durrant wrote:
> > > > > -----Original Message-----
> > > > > From: Ian Campbell
> > > > > Sent: 13 November 2013 09:41
> > > > > To: xen-devel
> > > > > Cc: Paul Durrant; Ian Jackson; Stefano Stabellini
> > > > > Subject: Multiple platform PCI device ID registries?
> > > > >
> > > > > http://xenbits.xen.org/docs/unstable-staging/misc/pci-device-
> > > > > reservations.txt
> > > > > vs
> > > > > http://xenbits.xen.org/docs/unstable-
> > > > > staging/hypercall/x86_64/include,public,hvm,pvdrivers.h.html
> > > > >
> > > > > Are they distinct namespaces? Can someone clarify with a patch to
> one or
> > > > > both what the relationship is? How does this relate to the additional
> > > > > platform device thing which Paul added to qemu?
> > > > >
> > > > > I'm particularly concerned that 0x0002 is different in the two of
> > > > > them...
> > > > >
> > > >
> > > > They are distinct namespaces. The former is PCI device ID, the latter
> > > > is an abstract 'product number' which is used as part of the QEMU
> > > > unplug protocol (and actually means nothing to the upstream QEMU
> > > > platform device code anyway).
> > >
> > > I'm confused then. qemu.git:
> > >         commit 8fbab3b62a271526c782110aed0ae160eb38c296
> > >         Author: Paul Durrant <paul.durrant@citrix.com>
> > >         Date:   Mon Jul 29 10:58:01 2013 +0000
> > >
> > >             Xen PV Device
> > >
> > >             Introduces a new Xen PV PCI device which will act as a binding point
> for
> > >             PV drivers for Xen.
> > >             The device has parameterized vendor-id, device-id and revision to
> > > allow to
> > >             be configured as a binding point for any vendor's PV drivers.
> > >
> > >             Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > >             Signed-off-by: Stefano Stabellini
> <stefano.stabellini@eu.citrix.com>
> > >             Reviewed-by: Andreas Färber <afaerber@suse.de>
> > >
> > > Adds a new device with parameterized vendor and device-id, which
> sounds
> > > like a pci-device-reservations.txt thing. But you reserved entries in
> > > the pvdrivers.h list which is a "product number" thing? Maybe I'm
> > > confusing two different events?
> > >
> >
> > Yes, they are completely distinct things. Not related in the slightest.
> 
> OK!
> 
> > The former was to add a parameterized device which we can use to hang
> > PV drivers off for Windows Update purposes.
> > The latter was add reservations for a product numbers that is already
> > in use in XenServer, and another one which we will use going forward
> > that - by reserving it - should now not conflict with anyone else's PV
> > drivers in future (if anyone cares to add product-number-based
> > blacklisting into upstream QEMU or amend the code in trad.)
> >
> > > That patch uses device ID
> > > #define PCI_DEVICE_ID_XEN_PVDEVICE       0x0002
> > >
> > > which appears to conflict with pci-device-reservations.txt which says
> > > that devid 2 is "Citrix XenServer (grandfathered allocation for
> > > XenServer 6.1)" Or maybe the comment there is just out of date?
> > >
> >
> > Using 2 seems safe as it doesn't conflict with the platform device ID
> > and we have now registered that ID.
> 
> You are referring to the registration in pci-device-reservations.txt,
> right?
> 

Yes.

> I'm concerned because that comment refers to XenServer 6.1 but it now
> appears to be being reused as the default device ID for the "Xen
> pvdevice".
> 
> Maybe it is safe to reuse this in this way, but the docs should be
> updated I think.
> 

I believe it is safe.

> >  In practice it should never be used as the device ID should always be
> > specified by the toolstack.
> 
> But it defaults to the Citrix ID -- is that wise? Wouldn't it be better
> to default to nothing?
> 

I guess we could default the prop to something like 0xffff and then fail the init fn if we find the value unmodified. Would that be better?

> It also seems to be causing a moderate amount of fallout in the
> "[Xen-devel] [BUG] Xen vm kernel crash in get_free_entries." thread.
> 

As I understood it, that problem is slightly distinct. It's a case of someone bringing up HVM linux in a XenServer VM and then getting a crash because PVonHVM doesn't set up properly due to the change in device_id for the *platform* device. Using device ID to for the PV device should not cause such fallout as the platform device is left unmolested.

> I'm busy wondering if maybe Qemu should blacklist non-xenserver product
> ids when it has been configured with the Xen PV device using the Citrix
> devid?
> 

That should not be necessary as the point of registering the devid is that on-one else creates driver that bind to that devid. Certainly no-one has to date.

  Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Multiple platform PCI device ID registries?

[Ian Campbell]

On Wed, 2013-11-13 at 11:58 +0000, Paul Durrant wrote:

> > I'm concerned because that comment refers to XenServer 6.1 but it now
> > appears to be being reused as the default device ID for the "Xen
> > pvdevice".
> > 
> > Maybe it is safe to reuse this in this way, but the docs should be
> > updated I think.
> > 
> 
> I believe it is safe.

How would you describe it in that document? "Xen PV device (extended
platform device). Previously used in XenServer 6.1" ?

Is there some spec we can link to regarding how this device should be
used?

> > >  In practice it should never be used as the device ID should always be
> > > specified by the toolstack.
> > 
> > But it defaults to the Citrix ID -- is that wise? Wouldn't it be better
> > to default to nothing?
> > 
> 
> I guess we could default the prop to something like 0xffff and then
> fail the init fn if we find the value unmodified. Would that be
> better?

I think so, yes.

> > It also seems to be causing a moderate amount of fallout in the
> > "[Xen-devel] [BUG] Xen vm kernel crash in get_free_entries." thread.
> > 
> 
> As I understood it, that problem is slightly distinct. It's a case of
> someone bringing up HVM linux in a XenServer VM and then getting a
> crash because PVonHVM doesn't set up properly due to the change in
> device_id for the *platform* device.

How and when did this change? Was it just a XenServer quirk in a
particular version?

>  Using device ID to for the PV device should not cause such fallout as
> the platform device is left unmolested.
> 
> > I'm busy wondering if maybe Qemu should blacklist non-xenserver product
> > ids when it has been configured with the Xen PV device using the Citrix
> > devid?
> > 
> 
> That should not be necessary as the point of registering the devid is
> that on-one else creates driver that bind to that devid. Certainly
> no-one has to date.

The problem is that unplug time we don't necessarily have PCI yet to
know if we are going to be able to bind to the device which eventually
shows up.

Remind me: When the PV device is in use the platform device must always
be present? Right? That's the sort of thing which should be mentioned in
the spec I asked about above.

Ian.

Re: Multiple platform PCI device ID registries?

[Paul Durrant]

> -----Original Message-----
> From: Ian Campbell
> Sent: 13 November 2013 12:09
> To: Paul Durrant
> Cc: xen-devel; Ian Jackson; Stefano Stabellini
> Subject: Re: Multiple platform PCI device ID registries?
> 
> On Wed, 2013-11-13 at 11:58 +0000, Paul Durrant wrote:
> 
> > > I'm concerned because that comment refers to XenServer 6.1 but it now
> > > appears to be being reused as the default device ID for the "Xen
> > > pvdevice".
> > >
> > > Maybe it is safe to reuse this in this way, but the docs should be
> > > updated I think.
> > >
> >
> > I believe it is safe.
> 
> How would you describe it in that document? "Xen PV device (extended
> platform device). Previously used in XenServer 6.1" ?
> 
> Is there some spec we can link to regarding how this device should be
> used?
> 
> > > >  In practice it should never be used as the device ID should always be
> > > > specified by the toolstack.
> > >
> > > But it defaults to the Citrix ID -- is that wise? Wouldn't it be better
> > > to default to nothing?
> > >
> >
> > I guess we could default the prop to something like 0xffff and then
> > fail the init fn if we find the value unmodified. Would that be
> > better?
> 
> I think so, yes.
> 
> > > It also seems to be causing a moderate amount of fallout in the
> > > "[Xen-devel] [BUG] Xen vm kernel crash in get_free_entries." thread.
> > >
> >
> > As I understood it, that problem is slightly distinct. It's a case of
> > someone bringing up HVM linux in a XenServer VM and then getting a
> > crash because PVonHVM doesn't set up properly due to the change in
> > device_id for the *platform* device.
> 
> How and when did this change? Was it just a XenServer quirk in a
> particular version?
> 

Yes, we changed it rather than adding the additional device as we believed that we may end up shipping drivers to Windows Update and did not want them to install on older XenServers. With hindsight that was the wrong thing to do; using and additional device is a much better solution.

> >  Using device ID to for the PV device should not cause such fallout as
> > the platform device is left unmolested.
> >
> > > I'm busy wondering if maybe Qemu should blacklist non-xenserver
> product
> > > ids when it has been configured with the Xen PV device using the Citrix
> > > devid?
> > >
> >
> > That should not be necessary as the point of registering the devid is
> > that on-one else creates driver that bind to that devid. Certainly
> > no-one has to date.
> 
> The problem is that unplug time we don't necessarily have PCI yet to
> know if we are going to be able to bind to the device which eventually
> shows up.
> 

The issue is entirely XenServer's problem though. No change should be needed upstream.
The background is that in 6.1, we used product nr 3 as it was the next unregistered number at the time. We subsequently found out that Linux PVonHVM was using this without having registered it. I thus registered it and moved the XenServer drivers onto product nr 4. Unfortunately we still have to allow people to use 6.1 drivers so we still have to allow drivers with product nr 3 to be used. I believe we can spot Linux PVonHVM though as the build number is always small so it would actually be feasible to blacklist Linux PVonHVM if the platform device_id is 2; hopefully that would stop the crashes. I'll add a patch to XenServer's QEMU patch queue to do that.

> Remind me: When the PV device is in use the platform device must always
> be present? Right? That's the sort of thing which should be mentioned in
> the spec I asked about above.
> 

Yes it does, otherwise you can't unplug emulated devices.

Given that you can't actually turn off the platform device in upstream QEMU with xl at the moment, I wonder whether the correct solution is simply to remove the option for doing so and have it always on in trad too.

  Paul

Re: Multiple platform PCI device ID registries?

[Ian Campbell]

On Wed, 2013-11-13 at 12:30 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 13 November 2013 12:09
> > To: Paul Durrant
> > Cc: xen-devel; Ian Jackson; Stefano Stabellini
> > Subject: Re: Multiple platform PCI device ID registries?
> > 
> > On Wed, 2013-11-13 at 11:58 +0000, Paul Durrant wrote:
> > 
> > > > I'm concerned because that comment refers to XenServer 6.1 but it now
> > > > appears to be being reused as the default device ID for the "Xen
> > > > pvdevice".
> > > >
> > > > Maybe it is safe to reuse this in this way, but the docs should be
> > > > updated I think.
> > > >
> > >
> > > I believe it is safe.
> > 
> > How would you describe it in that document? "Xen PV device (extended
> > platform device). Previously used in XenServer 6.1" ?
> > 
> > Is there some spec we can link to regarding how this device should be
> > used?

???

> > > > It also seems to be causing a moderate amount of fallout in the
> > > > "[Xen-devel] [BUG] Xen vm kernel crash in get_free_entries." thread.
> > > >
> > >
> > > As I understood it, that problem is slightly distinct. It's a case of
> > > someone bringing up HVM linux in a XenServer VM and then getting a
> > > crash because PVonHVM doesn't set up properly due to the change in
> > > device_id for the *platform* device.
> > 
> > How and when did this change? Was it just a XenServer quirk in a
> > particular version?
> > 
> 
> Yes, we changed it rather than adding the additional device as we
> believed that we may end up shipping drivers to Windows Update and did
> not want them to install on older XenServers. With hindsight that was
> the wrong thing to do; using and additional device is a much better
> solution.

This sounds like a tricky one to resolve compatibly in Linux -- we can't
just bind to device id 0x2 since that is now the Citrix ID for the PV
device.

Best bet is to just document "Don't Do That Then". Is there some
XenServer way we can tell people to fix this (by changing the ID back?)

> 
> > >  Using device ID to for the PV device should not cause such fallout as
> > > the platform device is left unmolested.
> > >
> > > > I'm busy wondering if maybe Qemu should blacklist non-xenserver
> > product
> > > > ids when it has been configured with the Xen PV device using the Citrix
> > > > devid?
> > > >
> > >
> > > That should not be necessary as the point of registering the devid is
> > > that on-one else creates driver that bind to that devid. Certainly
> > > no-one has to date.
> > 
> > The problem is that unplug time we don't necessarily have PCI yet to
> > know if we are going to be able to bind to the device which eventually
> > shows up.
> > 
> 
> The issue is entirely XenServer's problem though. No change should be
> needed upstream.

> The background is that in 6.1, we used product nr 3 as it was the next
> unregistered number at the time.

Product number, not device ID?

>  We subsequently found out that Linux PVonHVM was using this without
> having registered it. I thus registered it and moved the XenServer
> drivers onto product nr 4. Unfortunately we still have to allow people
> to use 6.1 drivers so we still have to allow drivers with product nr 3
> to be used. I believe we can spot Linux PVonHVM though as the build
> number is always small so it would actually be feasible to blacklist
> Linux PVonHVM if the platform device_id is 2; hopefully that would
> stop the crashes. I'll add a patch to XenServer's QEMU patch queue to
> do that.
> 
> > Remind me: When the PV device is in use the platform device must always
> > be present? Right? That's the sort of thing which should be mentioned in
> > the spec I asked about above.
> > 
> 
> Yes it does, otherwise you can't unplug emulated devices.
> 
> Given that you can't actually turn off the platform device in upstream
> QEMU with xl at the moment, I wonder whether the correct solution is
> simply to remove the option for doing so and have it always on in trad
> too.

I think "no platform device and no pv device" is a valid and useful
configuration, meaning "use emulated devices". "no platform device, yes
pv device" is the one to avoid.

Ian.

Re: Multiple platform PCI device ID registries?

[Paul Durrant]

> -----Original Message-----
> From: Ian Campbell
> Sent: 13 November 2013 12:39
> To: Paul Durrant
> Cc: xen-devel; Ian Jackson; Stefano Stabellini
> Subject: Re: Multiple platform PCI device ID registries?
> 
> On Wed, 2013-11-13 at 12:30 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 13 November 2013 12:09
> > > To: Paul Durrant
> > > Cc: xen-devel; Ian Jackson; Stefano Stabellini
> > > Subject: Re: Multiple platform PCI device ID registries?
> > >
> > > On Wed, 2013-11-13 at 11:58 +0000, Paul Durrant wrote:
> > >
> > > > > I'm concerned because that comment refers to XenServer 6.1 but it
> now
> > > > > appears to be being reused as the default device ID for the "Xen
> > > > > pvdevice".
> > > > >
> > > > > Maybe it is safe to reuse this in this way, but the docs should be
> > > > > updated I think.
> > > > >
> > > >
> > > > I believe it is safe.
> > >
> > > How would you describe it in that document? "Xen PV device (extended
> > > platform device). Previously used in XenServer 6.1" ?
> > >
> > > Is there some spec we can link to regarding how this device should be
> > > used?
> 
> ???

Sorry, missed that.

No, it wasn't previously used in 6.1 because it's not really the same (as the pv device doesn't implement the fixed IO ports). I also don't want to confuse it with the platform device, for that reason. It is a new distinct and I agree that the fact it defaults to device ID is confusing although it's safe - I will therefore submit a patch to QEMU to modify it as I suggested before, so that the id *must* be specified by the toolstack.

> 
> > > > > It also seems to be causing a moderate amount of fallout in the
> > > > > "[Xen-devel] [BUG] Xen vm kernel crash in get_free_entries." thread.
> > > > >
> > > >
> > > > As I understood it, that problem is slightly distinct. It's a case of
> > > > someone bringing up HVM linux in a XenServer VM and then getting a
> > > > crash because PVonHVM doesn't set up properly due to the change in
> > > > device_id for the *platform* device.
> > >
> > > How and when did this change? Was it just a XenServer quirk in a
> > > particular version?
> > >
> >
> > Yes, we changed it rather than adding the additional device as we
> > believed that we may end up shipping drivers to Windows Update and did
> > not want them to install on older XenServers. With hindsight that was
> > the wrong thing to do; using and additional device is a much better
> > solution.
> 
> This sounds like a tricky one to resolve compatibly in Linux -- we can't
> just bind to device id 0x2 since that is now the Citrix ID for the PV
> device.

Yes, probably best not to go there, even when I do fix the PV device.

> 
> Best bet is to just document "Don't Do That Then". Is there some
> XenServer way we can tell people to fix this (by changing the ID back?)
> 

Well part of the problem is that we don't support use of PVonHVM linux in XenServer at all! The best thing is probably to tackle this on the XenServer forums if and when someone posts the problem there. Adding the extra blacklisting code to XenServer's QEMU and then getting that into a hotfix should hopefully avoid future problems too - although we may get 'why are my PV frontends not working?'-type questions.

> >
> > > >  Using device ID to for the PV device should not cause such fallout as
> > > > the platform device is left unmolested.
> > > >
> > > > > I'm busy wondering if maybe Qemu should blacklist non-xenserver
> > > product
> > > > > ids when it has been configured with the Xen PV device using the
> Citrix
> > > > > devid?
> > > > >
> > > >
> > > > That should not be necessary as the point of registering the devid is
> > > > that on-one else creates driver that bind to that devid. Certainly
> > > > no-one has to date.
> > >
> > > The problem is that unplug time we don't necessarily have PCI yet to
> > > know if we are going to be able to bind to the device which eventually
> > > shows up.
> > >
> >
> > The issue is entirely XenServer's problem though. No change should be
> > needed upstream.
> 
> > The background is that in 6.1, we used product nr 3 as it was the next
> > unregistered number at the time.
> 
> Product number, not device ID?
> 
> >  We subsequently found out that Linux PVonHVM was using this without
> > having registered it. I thus registered it and moved the XenServer
> > drivers onto product nr 4. Unfortunately we still have to allow people
> > to use 6.1 drivers so we still have to allow drivers with product nr 3
> > to be used. I believe we can spot Linux PVonHVM though as the build
> > number is always small so it would actually be feasible to blacklist
> > Linux PVonHVM if the platform device_id is 2; hopefully that would
> > stop the crashes. I'll add a patch to XenServer's QEMU patch queue to
> > do that.
> >
> > > Remind me: When the PV device is in use the platform device must
> always
> > > be present? Right? That's the sort of thing which should be mentioned in
> > > the spec I asked about above.
> > >
> >
> > Yes it does, otherwise you can't unplug emulated devices.
> >
> > Given that you can't actually turn off the platform device in upstream
> > QEMU with xl at the moment, I wonder whether the correct solution is
> > simply to remove the option for doing so and have it always on in trad
> > too.
> 
> I think "no platform device and no pv device" is a valid and useful
> configuration, meaning "use emulated devices". "no platform device, yes
> pv device" is the one to avoid.
> 

Hmm. How about splitting out the fixed IO ports then? That way the platform device could be safely turned off if the PV device was present. It seems like a cleaner and safer thing to do.

  Paul

Re: Multiple platform PCI device ID registries?

[Ian Campbell]

On Wed, 2013-11-13 at 12:50 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 13 November 2013 12:39
> > To: Paul Durrant
> > Cc: xen-devel; Ian Jackson; Stefano Stabellini
> > Subject: Re: Multiple platform PCI device ID registries?
> > 
> > On Wed, 2013-11-13 at 12:30 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > Sent: 13 November 2013 12:09
> > > > To: Paul Durrant
> > > > Cc: xen-devel; Ian Jackson; Stefano Stabellini
> > > > Subject: Re: Multiple platform PCI device ID registries?
> > > >
> > > > On Wed, 2013-11-13 at 11:58 +0000, Paul Durrant wrote:
> > > >
> > > > > > I'm concerned because that comment refers to XenServer 6.1 but it
> > now
> > > > > > appears to be being reused as the default device ID for the "Xen
> > > > > > pvdevice".
> > > > > >
> > > > > > Maybe it is safe to reuse this in this way, but the docs should be
> > > > > > updated I think.
> > > > > >
> > > > >
> > > > > I believe it is safe.
> > > >
> > > > How would you describe it in that document? "Xen PV device (extended
> > > > platform device). Previously used in XenServer 6.1" ?
> > > >
> > > > Is there some spec we can link to regarding how this device should be
> > > > used?
> > 
> > ???
> 
> Sorry, missed that.

You've missed the part about a link to a spec for what the Xen PV device
is, when it should appear, how it relates to the platform device again

> No, it wasn't previously used in 6.1 because it's not really the same
> (as the pv device doesn't implement the fixed IO ports). I also don't
> want to confuse it with the platform device, for that reason. It is a
> new distinct and I agree that the fact it defaults to device ID is
> confusing although it's safe - I will therefore submit a patch to QEMU
> to modify it as I suggested before, so that the id *must* be specified
> by the toolstack.

Ack.

> > 
> > Best bet is to just document "Don't Do That Then". Is there some
> > XenServer way we can tell people to fix this (by changing the ID back?)
> > 
> 
> Well part of the problem is that we don't support use of PVonHVM linux
> in XenServer at all! The best thing is probably to tackle this on the
> XenServer forums if and when someone posts the problem there. Adding
> the extra blacklisting code to XenServer's QEMU and then getting that
> into a hotfix should hopefully avoid future problems too - although we
> may get 'why are my PV frontends not working?'-type questions.

Ah, I see now why it is a XS side fix.

> > I think "no platform device and no pv device" is a valid and useful
> > configuration, meaning "use emulated devices". "no platform device, yes
> > pv device" is the one to avoid.
> > 
> 
> Hmm. How about splitting out the fixed IO ports then? That way the
> platform device could be safely turned off if the PV device was
> present. It seems like a cleaner and safer thing to do.

I thought when the PV device was added it was agreed that it would only
ever be as an extension to the platform device, not a replacement for
it.

Otherwise you get into situations where cloud providers need to know
which to provide, whereas with a baseline platform device always there
things can try and work.

Ian.

Re: Multiple platform PCI device ID registries?

[Paul Durrant]

> -----Original Message-----
> From: Ian Campbell
> Sent: 13 November 2013 13:14
> To: Paul Durrant
> Cc: xen-devel; Ian Jackson; Stefano Stabellini
> Subject: Re: Multiple platform PCI device ID registries?
> 
> On Wed, 2013-11-13 at 12:50 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 13 November 2013 12:39
> > > To: Paul Durrant
> > > Cc: xen-devel; Ian Jackson; Stefano Stabellini
> > > Subject: Re: Multiple platform PCI device ID registries?
> > >
> > > On Wed, 2013-11-13 at 12:30 +0000, Paul Durrant wrote:
> > > > > -----Original Message-----
> > > > > From: Ian Campbell
> > > > > Sent: 13 November 2013 12:09
> > > > > To: Paul Durrant
> > > > > Cc: xen-devel; Ian Jackson; Stefano Stabellini
> > > > > Subject: Re: Multiple platform PCI device ID registries?
> > > > >
> > > > > On Wed, 2013-11-13 at 11:58 +0000, Paul Durrant wrote:
> > > > >
> > > > > > > I'm concerned because that comment refers to XenServer 6.1 but
> it
> > > now
> > > > > > > appears to be being reused as the default device ID for the "Xen
> > > > > > > pvdevice".
> > > > > > >
> > > > > > > Maybe it is safe to reuse this in this way, but the docs should be
> > > > > > > updated I think.
> > > > > > >
> > > > > >
> > > > > > I believe it is safe.
> > > > >
> > > > > How would you describe it in that document? "Xen PV device
> (extended
> > > > > platform device). Previously used in XenServer 6.1" ?
> > > > >
> > > > > Is there some spec we can link to regarding how this device should be
> > > > > used?
> > >
> > > ???
> >
> > Sorry, missed that.
> 
> You've missed the part about a link to a spec for what the Xen PV device
> is, when it should appear, how it relates to the platform device again

Oh sorry - too many emails in different threads... No, there is no spec. in existence. The xl.cfg manpage refers readers to pci-device-reservations.txt so I guess that would be the best place to add some words.

> 
> > No, it wasn't previously used in 6.1 because it's not really the same
> > (as the pv device doesn't implement the fixed IO ports). I also don't
> > want to confuse it with the platform device, for that reason. It is a
> > new distinct and I agree that the fact it defaults to device ID is
> > confusing although it's safe - I will therefore submit a patch to QEMU
> > to modify it as I suggested before, so that the id *must* be specified
> > by the toolstack.
> 
> Ack.
> 
> > >
> > > Best bet is to just document "Don't Do That Then". Is there some
> > > XenServer way we can tell people to fix this (by changing the ID back?)
> > >
> >
> > Well part of the problem is that we don't support use of PVonHVM linux
> > in XenServer at all! The best thing is probably to tackle this on the
> > XenServer forums if and when someone posts the problem there. Adding
> > the extra blacklisting code to XenServer's QEMU and then getting that
> > into a hotfix should hopefully avoid future problems too - although we
> > may get 'why are my PV frontends not working?'-type questions.
> 
> Ah, I see now why it is a XS side fix.
> 
> > > I think "no platform device and no pv device" is a valid and useful
> > > configuration, meaning "use emulated devices". "no platform device, yes
> > > pv device" is the one to avoid.
> > >
> >
> > Hmm. How about splitting out the fixed IO ports then? That way the
> > platform device could be safely turned off if the PV device was
> > present. It seems like a cleaner and safer thing to do.
> 
> I thought when the PV device was added it was agreed that it would only
> ever be as an extension to the platform device, not a replacement for
> it.
> 
> Otherwise you get into situations where cloud providers need to know
> which to provide, whereas with a baseline platform device always there
> things can try and work.
> 

Yes, agreed, it is intended as an extra device but the fact that removing the *PCI* platform device from the VM disables the fixed IO ports is somewhat counter-intuitive so I was proposing that should be fixed. Then *if* someone had the PV device and removed the platform device any bound PV frontends would continue to function.

  Paul

Re: Multiple platform PCI device ID registries?

[Ian Campbell]

On Wed, 2013-11-13 at 13:25 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 13 November 2013 13:14
> > To: Paul Durrant
> > Cc: xen-devel; Ian Jackson; Stefano Stabellini
> > Subject: Re: Multiple platform PCI device ID registries?
> > 
> > On Wed, 2013-11-13 at 12:50 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > Sent: 13 November 2013 12:39
> > > > To: Paul Durrant
> > > > Cc: xen-devel; Ian Jackson; Stefano Stabellini
> > > > Subject: Re: Multiple platform PCI device ID registries?
> > > >
> > > > On Wed, 2013-11-13 at 12:30 +0000, Paul Durrant wrote:
> > > > > > -----Original Message-----
> > > > > > From: Ian Campbell
> > > > > > Sent: 13 November 2013 12:09
> > > > > > To: Paul Durrant
> > > > > > Cc: xen-devel; Ian Jackson; Stefano Stabellini
> > > > > > Subject: Re: Multiple platform PCI device ID registries?
> > > > > >
> > > > > > On Wed, 2013-11-13 at 11:58 +0000, Paul Durrant wrote:
> > > > > >
> > > > > > > > I'm concerned because that comment refers to XenServer 6.1 but
> > it
> > > > now
> > > > > > > > appears to be being reused as the default device ID for the "Xen
> > > > > > > > pvdevice".
> > > > > > > >
> > > > > > > > Maybe it is safe to reuse this in this way, but the docs should be
> > > > > > > > updated I think.
> > > > > > > >
> > > > > > >
> > > > > > > I believe it is safe.
> > > > > >
> > > > > > How would you describe it in that document? "Xen PV device
> > (extended
> > > > > > platform device). Previously used in XenServer 6.1" ?
> > > > > >
> > > > > > Is there some spec we can link to regarding how this device should be
> > > > > > used?
> > > >
> > > > ???
> > >
> > > Sorry, missed that.
> > 
> > You've missed the part about a link to a spec for what the Xen PV device
> > is, when it should appear, how it relates to the platform device again
> 
> Oh sorry - too many emails in different threads... No, there is no
> spec. in existence. The xl.cfg manpage refers readers to
> pci-device-reservations.txt so I guess that would be the best place to
> add some words.

Do you think you could do that? I'm clearly to confused to write
anything useful...

> 
> > 
> > > No, it wasn't previously used in 6.1 because it's not really the same
> > > (as the pv device doesn't implement the fixed IO ports). I also don't
> > > want to confuse it with the platform device, for that reason. It is a
> > > new distinct and I agree that the fact it defaults to device ID is
> > > confusing although it's safe - I will therefore submit a patch to QEMU
> > > to modify it as I suggested before, so that the id *must* be specified
> > > by the toolstack.
> > 
> > Ack.
> > 
> > > >
> > > > Best bet is to just document "Don't Do That Then". Is there some
> > > > XenServer way we can tell people to fix this (by changing the ID back?)
> > > >
> > >
> > > Well part of the problem is that we don't support use of PVonHVM linux
> > > in XenServer at all! The best thing is probably to tackle this on the
> > > XenServer forums if and when someone posts the problem there. Adding
> > > the extra blacklisting code to XenServer's QEMU and then getting that
> > > into a hotfix should hopefully avoid future problems too - although we
> > > may get 'why are my PV frontends not working?'-type questions.
> > 
> > Ah, I see now why it is a XS side fix.
> > 
> > > > I think "no platform device and no pv device" is a valid and useful
> > > > configuration, meaning "use emulated devices". "no platform device, yes
> > > > pv device" is the one to avoid.
> > > >
> > >
> > > Hmm. How about splitting out the fixed IO ports then? That way the
> > > platform device could be safely turned off if the PV device was
> > > present. It seems like a cleaner and safer thing to do.
> > 
> > I thought when the PV device was added it was agreed that it would only
> > ever be as an extension to the platform device, not a replacement for
> > it.
> > 
> > Otherwise you get into situations where cloud providers need to know
> > which to provide, whereas with a baseline platform device always there
> > things can try and work.
> > 
> 
> Yes, agreed, it is intended as an extra device but the fact that
> removing the *PCI* platform device from the VM disables the fixed IO
> ports is somewhat counter-intuitive so I was proposing that should be
> fixed. Then *if* someone had the PV device and removed the platform
> device any bound PV frontends would continue to function.

If someone removes the platform device then this should cause the PV
device to be removed or for configurations which specify PV but not
platform device to be rejected.

Ian.

Re: Multiple platform PCI device ID registries?

[Paul Durrant]

> -----Original Message-----
> From: Ian Campbell
> Sent: 13 November 2013 13:27
> To: Paul Durrant
> Cc: xen-devel; Ian Jackson; Stefano Stabellini
> Subject: Re: Multiple platform PCI device ID registries?
> 
> On Wed, 2013-11-13 at 13:25 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 13 November 2013 13:14
> > > To: Paul Durrant
> > > Cc: xen-devel; Ian Jackson; Stefano Stabellini
> > > Subject: Re: Multiple platform PCI device ID registries?
> > >
> > > On Wed, 2013-11-13 at 12:50 +0000, Paul Durrant wrote:
> > > > > -----Original Message-----
> > > > > From: Ian Campbell
> > > > > Sent: 13 November 2013 12:39
> > > > > To: Paul Durrant
> > > > > Cc: xen-devel; Ian Jackson; Stefano Stabellini
> > > > > Subject: Re: Multiple platform PCI device ID registries?
> > > > >
> > > > > On Wed, 2013-11-13 at 12:30 +0000, Paul Durrant wrote:
> > > > > > > -----Original Message-----
> > > > > > > From: Ian Campbell
> > > > > > > Sent: 13 November 2013 12:09
> > > > > > > To: Paul Durrant
> > > > > > > Cc: xen-devel; Ian Jackson; Stefano Stabellini
> > > > > > > Subject: Re: Multiple platform PCI device ID registries?
> > > > > > >
> > > > > > > On Wed, 2013-11-13 at 11:58 +0000, Paul Durrant wrote:
> > > > > > >
> > > > > > > > > I'm concerned because that comment refers to XenServer 6.1
> but
> > > it
> > > > > now
> > > > > > > > > appears to be being reused as the default device ID for the
> "Xen
> > > > > > > > > pvdevice".
> > > > > > > > >
> > > > > > > > > Maybe it is safe to reuse this in this way, but the docs should
> be
> > > > > > > > > updated I think.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I believe it is safe.
> > > > > > >
> > > > > > > How would you describe it in that document? "Xen PV device
> > > (extended
> > > > > > > platform device). Previously used in XenServer 6.1" ?
> > > > > > >
> > > > > > > Is there some spec we can link to regarding how this device should
> be
> > > > > > > used?
> > > > >
> > > > > ???
> > > >
> > > > Sorry, missed that.
> > >
> > > You've missed the part about a link to a spec for what the Xen PV device
> > > is, when it should appear, how it relates to the platform device again
> >
> > Oh sorry - too many emails in different threads... No, there is no
> > spec. in existence. The xl.cfg manpage refers readers to
> > pci-device-reservations.txt so I guess that would be the best place to
> > add some words.
> 
> Do you think you could do that? I'm clearly to confused to write
> anything useful...
> 

Ok. Will do. Just doing the QEMU things first.

> >
> > >
> > > > No, it wasn't previously used in 6.1 because it's not really the same
> > > > (as the pv device doesn't implement the fixed IO ports). I also don't
> > > > want to confuse it with the platform device, for that reason. It is a
> > > > new distinct and I agree that the fact it defaults to device ID is
> > > > confusing although it's safe - I will therefore submit a patch to QEMU
> > > > to modify it as I suggested before, so that the id *must* be specified
> > > > by the toolstack.
> > >
> > > Ack.
> > >
> > > > >
> > > > > Best bet is to just document "Don't Do That Then". Is there some
> > > > > XenServer way we can tell people to fix this (by changing the ID
> back?)
> > > > >
> > > >
> > > > Well part of the problem is that we don't support use of PVonHVM
> linux
> > > > in XenServer at all! The best thing is probably to tackle this on the
> > > > XenServer forums if and when someone posts the problem there.
> Adding
> > > > the extra blacklisting code to XenServer's QEMU and then getting that
> > > > into a hotfix should hopefully avoid future problems too - although we
> > > > may get 'why are my PV frontends not working?'-type questions.
> > >
> > > Ah, I see now why it is a XS side fix.
> > >
> > > > > I think "no platform device and no pv device" is a valid and useful
> > > > > configuration, meaning "use emulated devices". "no platform device,
> yes
> > > > > pv device" is the one to avoid.
> > > > >
> > > >
> > > > Hmm. How about splitting out the fixed IO ports then? That way the
> > > > platform device could be safely turned off if the PV device was
> > > > present. It seems like a cleaner and safer thing to do.
> > >
> > > I thought when the PV device was added it was agreed that it would only
> > > ever be as an extension to the platform device, not a replacement for
> > > it.
> > >
> > > Otherwise you get into situations where cloud providers need to know
> > > which to provide, whereas with a baseline platform device always there
> > > things can try and work.
> > >
> >
> > Yes, agreed, it is intended as an extra device but the fact that
> > removing the *PCI* platform device from the VM disables the fixed IO
> > ports is somewhat counter-intuitive so I was proposing that should be
> > fixed. Then *if* someone had the PV device and removed the platform
> > device any bound PV frontends would continue to function.
> 
> If someone removes the platform device then this should cause the PV
> device to be removed or for configurations which specify PV but not
> platform device to be rejected.
> 

Ok then. That's what will happen today so I'll mention it in the doc.

  Paul

Re: Multiple platform PCI device ID registries?

[Ian Campbell]

On Wed, 2013-11-13 at 13:30 +0000, Paul Durrant wrote:
> > > Oh sorry - too many emails in different threads... No, there is no
> > > spec. in existence. The xl.cfg manpage refers readers to
> > > pci-device-reservations.txt so I guess that would be the best place to
> > > add some words.
> > 
> > Do you think you could do that? I'm clearly to confused to write
> > anything useful...
> > 
> 
> Ok. Will do. Just doing the QEMU things first.

Thanks.

> > If someone removes the platform device then this should cause the PV
> > device to be removed or for configurations which specify PV but not
> > platform device to be rejected.
> > 
> 
> Ok then. That's what will happen today so I'll mention it in the doc.

Perfect.

Cheers,
Ian.

Re: Multiple platform PCI device ID registries?

[Pasi Kärkkäinen]

On Wed, Nov 13, 2013 at 12:50:47PM +0000, Paul Durrant wrote:
> 
> Well part of the problem is that we don't support use of PVonHVM linux in XenServer at all! The best thing is probably to tackle this on the XenServer forums if and when someone posts the problem there. Adding the extra blacklisting code to XenServer's QEMU and then getting that into a hotfix should hopefully avoid future problems too - although we may get 'why are my PV frontends not working?'-type questions.
> 

.. although I hope support for PVHVM Linux will be added to XenServer soon!


-- Pasi

Re: Multiple platform PCI device ID registries?

[Paul Durrant]

> -----Original Message-----
> From: Pasi Kärkkäinen [mailto:pasik@iki.fi]
> Sent: 13 November 2013 15:37
> To: Paul Durrant
> Cc: Ian Campbell; xen-devel
> Subject: Re: [Xen-devel] Multiple platform PCI device ID registries?
> 
> On Wed, Nov 13, 2013 at 12:50:47PM +0000, Paul Durrant wrote:
> >
> > Well part of the problem is that we don't support use of PVonHVM linux in
> XenServer at all! The best thing is probably to tackle this on the XenServer
> forums if and when someone posts the problem there. Adding the extra
> blacklisting code to XenServer's QEMU and then getting that into a hotfix
> should hopefully avoid future problems too - although we may get 'why are
> my PV frontends not working?'-type questions.
> >
> 
> .. although I hope support for PVHVM Linux will be added to XenServer soon!
> 

I hope so too. Not my call though.

  Paul