[PATCH] Register PV driver product numbers 4 and 5.

[PATCH] Register PV driver product numbers 4 and 5.

[Paul Durrant]

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
---
 xen/include/public/hvm/pvdrivers.h |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h
index 4c6b705..77994d2 100644
--- a/xen/include/public/hvm/pvdrivers.h
+++ b/xen/include/public/hvm/pvdrivers.h
@@ -38,10 +38,12 @@
  * indicate a driver which is yet to be released.
  */
 
-#define PVDRIVERS_PRODUCT_LIST(EACH)                         \
-        EACH("xensource-windows", 0x0001) /* Citrix */       \
-        EACH("gplpv-windows",     0x0002) /* James Harper */ \
-        EACH("linux",             0x0003)                    \
-        EACH("experimental",      0xffff)
+#define PVDRIVERS_PRODUCT_LIST(EACH)                               \
+        EACH("xensource-windows",       0x0001) /* Citrix */       \
+        EACH("gplpv-windows",           0x0002) /* James Harper */ \
+        EACH("linux",                   0x0003)                    \
+        EACH("xenserver-windows-v7.0+", 0x0004) /* Citrix */       \
+        EACH("xenserver-windows-v7.2+", 0x0005) /* Citrix */       \
+        EACH("experimental",            0xffff)
 
 #endif /* _XEN_PUBLIC_PVDRIVERS_H_ */
-- 
1.7.10.4

Re: [PATCH] Register PV driver product numbers 4 and 5.

[Ian Campbell]

On Mon, 2013-09-30 at 12:18 +0100, Paul Durrant wrote:
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> ---
>  xen/include/public/hvm/pvdrivers.h |   12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h
> index 4c6b705..77994d2 100644
> --- a/xen/include/public/hvm/pvdrivers.h
> +++ b/xen/include/public/hvm/pvdrivers.h
> @@ -38,10 +38,12 @@
>   * indicate a driver which is yet to be released.
>   */
>  
> -#define PVDRIVERS_PRODUCT_LIST(EACH)                         \
> -        EACH("xensource-windows", 0x0001) /* Citrix */       \
> -        EACH("gplpv-windows",     0x0002) /* James Harper */ \
> -        EACH("linux",             0x0003)                    \
> -        EACH("experimental",      0xffff)
> +#define PVDRIVERS_PRODUCT_LIST(EACH)                               \
> +        EACH("xensource-windows",       0x0001) /* Citrix */       \
> +        EACH("gplpv-windows",           0x0002) /* James Harper */ \
> +        EACH("linux",                   0x0003)                    \
> +        EACH("xenserver-windows-v7.0+", 0x0004) /* Citrix */       \
> +        EACH("xenserver-windows-v7.2+", 0x0005) /* Citrix */       \

The unplug protocol includes
        4. The drivers write a four-byte build number to IO port `0x10`.
Can't you use that instead of defining a new product for each version of
your drivers?

How does this interact with the use of the alternative platform device
thing which you added? Does docs/misc/hvm-emulated-unplug.markdown need
expanding to cover that case?

I notice that docs/misc/hvm-emulated-unplug.markdown also says:
        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.
which isn't accurate any longer...

> +        EACH("experimental",            0xffff)
>  
>  #endif /* _XEN_PUBLIC_PVDRIVERS_H_ */

Re: [PATCH] Register PV driver product numbers 4 and 5.

[Paul Durrant]

> -----Original Message-----
> From: Ian Campbell
> Sent: 03 October 2013 14:19
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH] Register PV driver product numbers 4 and
> 5.
> 
> On Mon, 2013-09-30 at 12:18 +0100, Paul Durrant wrote:
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > ---
> >  xen/include/public/hvm/pvdrivers.h |   12 +++++++-----
> >  1 file changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/xen/include/public/hvm/pvdrivers.h
> b/xen/include/public/hvm/pvdrivers.h
> > index 4c6b705..77994d2 100644
> > --- a/xen/include/public/hvm/pvdrivers.h
> > +++ b/xen/include/public/hvm/pvdrivers.h
> > @@ -38,10 +38,12 @@
> >   * indicate a driver which is yet to be released.
> >   */
> >
> > -#define PVDRIVERS_PRODUCT_LIST(EACH)                         \
> > -        EACH("xensource-windows", 0x0001) /* Citrix */       \
> > -        EACH("gplpv-windows",     0x0002) /* James Harper */ \
> > -        EACH("linux",             0x0003)                    \
> > -        EACH("experimental",      0xffff)
> > +#define PVDRIVERS_PRODUCT_LIST(EACH)                               \
> > +        EACH("xensource-windows",       0x0001) /* Citrix */       \
> > +        EACH("gplpv-windows",           0x0002) /* James Harper */ \
> > +        EACH("linux",                   0x0003)                    \
> > +        EACH("xenserver-windows-v7.0+", 0x0004) /* Citrix */       \
> > +        EACH("xenserver-windows-v7.2+", 0x0005) /* Citrix */       \
> 
> The unplug protocol includes
>         4. The drivers write a four-byte build number to IO port `0x10`.
> Can't you use that instead of defining a new product for each version of
> your drivers?
> 

Unfortunately I need to grandfather in 4 because it's used in XenServer (and cause the patched version of QEMU therein to behave in a slightly funky way). I wanted to reserve 5 because it's not been used in XenServer so far and therefore has no odd semantics attached to it and so I intend to use it for the newer Windows-Update-ready drivers, which I don't need to be able to blacklist in the 'old' way as they're designed to work with upstream QEMU where there is no implementation of blacklisting.
I was originally intending to use 1, but that also has been messed with in XenServer to work around some compatibility problems.

> How does this interact with the use of the alternative platform device
> thing which you added? Does docs/misc/hvm-emulated-unplug.markdown
> need
> expanding to cover that case?
> 

No, I still use the traditional unplug protocol and will respect blacklisting if anyone cares to implement it for product number 5 but, as I said, I don't anticipate the need for it.

> I notice that docs/misc/hvm-emulated-unplug.markdown also says:
>         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.
> which isn't accurate any longer...
> 

True, but then Linux PVonHVM didn't register product number 3 either, which is what led to a lot of the craziness leading to me now having to register 4 and 5.

  Paul

Re: [PATCH] Register PV driver product numbers 4 and 5.

[Ian Campbell]

On Thu, 2013-10-03 at 15:19 +0100, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 03 October 2013 14:19
> > To: Paul Durrant
> > Cc: xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] [PATCH] Register PV driver product numbers 4 and
> > 5.
> > 
> > On Mon, 2013-09-30 at 12:18 +0100, Paul Durrant wrote:
> > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > > ---
> > >  xen/include/public/hvm/pvdrivers.h |   12 +++++++-----
> > >  1 file changed, 7 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/xen/include/public/hvm/pvdrivers.h
> > b/xen/include/public/hvm/pvdrivers.h
> > > index 4c6b705..77994d2 100644
> > > --- a/xen/include/public/hvm/pvdrivers.h
> > > +++ b/xen/include/public/hvm/pvdrivers.h
> > > @@ -38,10 +38,12 @@
> > >   * indicate a driver which is yet to be released.
> > >   */
> > >
> > > -#define PVDRIVERS_PRODUCT_LIST(EACH)                         \
> > > -        EACH("xensource-windows", 0x0001) /* Citrix */       \
> > > -        EACH("gplpv-windows",     0x0002) /* James Harper */ \
> > > -        EACH("linux",             0x0003)                    \
> > > -        EACH("experimental",      0xffff)
> > > +#define PVDRIVERS_PRODUCT_LIST(EACH)                               \
> > > +        EACH("xensource-windows",       0x0001) /* Citrix */       \
> > > +        EACH("gplpv-windows",           0x0002) /* James Harper */ \
> > > +        EACH("linux",                   0x0003)                    \
> > > +        EACH("xenserver-windows-v7.0+", 0x0004) /* Citrix */       \
> > > +        EACH("xenserver-windows-v7.2+", 0x0005) /* Citrix */       \
> > 
> > The unplug protocol includes
> >         4. The drivers write a four-byte build number to IO port `0x10`.
> > Can't you use that instead of defining a new product for each version of
> > your drivers?
> > 
> 
> Unfortunately I need to grandfather in 4 because it's used in
> XenServer (and cause the patched version of QEMU therein to behave in
> a slightly funky way). I wanted to reserve 5 because it's not been
> used in XenServer so far and therefore has no odd semantics attached
> to it and so I intend to use it for the newer Windows-Update-ready
> drivers, which I don't need to be able to blacklist in the 'old' way
> as they're designed to work with upstream QEMU where there is no
> implementation of blacklisting.

./hw/xen/xen_platform.c seems to have support for blacklisting in it. Or
did you mean hw/xen/xen_pvdevice?

> I was originally intending to use 1, but that also has been messed
> with in XenServer to work around some compatibility problems.
> 
> > How does this interact with the use of the alternative platform device
> > thing which you added? Does docs/misc/hvm-emulated-unplug.markdown
> > need
> > expanding to cover that case?
> > 
> 
> No, I still use the traditional unplug protocol and will respect
> blacklisting

Hrm, what is the traditional unplug protocol? Something other than
docs/misc/hvm-emulated-unplug.markdown?

Assuming it is that, xen_pvdevice doesn't seem to implement any of it,
won't the drivers therefore abort at #1?"  If the magic number doesn't
match, the drivers don't do anything."?

>  if anyone cares to implement it for product number 5 but, as I said,
> I don't anticipate the need for it.

So product 5 is intended to be the same thing no matter whether you use
xen_platform or xen_pvdevice and no matter which vendor/device ID is
configured? You can only make this true for Citrix vendor ids I think,
or do you intend this to be binding for everyone?

I think that doc should be expanded to at least mention what is going on
here, since there are a lot of reasonable options and it's not clear to
me at least which one we are following.

> > I notice that docs/misc/hvm-emulated-unplug.markdown also says:
> >         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.
> > which isn't accurate any longer...
> > 
> 
> True, but then Linux PVonHVM didn't register product number 3 either,
> which is what led to a lot of the craziness leading to me now having
> to register 4 and 5.

I'm not sure I follow. How does PVHVM using 3 mean that you *have* to
reserve anything at all? I can see how given you need to register
something it now has to be 4 etc but that seems normal not crazy.

Ian

Re: [PATCH] Register PV driver product numbers 4 and 5.

[Paul Durrant]

> -----Original Message-----
> From: Ian Campbell
> Sent: 03 October 2013 15:33
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH] Register PV driver product numbers 4 and
> 5.
> 
> On Thu, 2013-10-03 at 15:19 +0100, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 03 October 2013 14:19
> > > To: Paul Durrant
> > > Cc: xen-devel@lists.xen.org
> > > Subject: Re: [Xen-devel] [PATCH] Register PV driver product numbers 4
> and
> > > 5.
> > >
> > > On Mon, 2013-09-30 at 12:18 +0100, Paul Durrant wrote:
> > > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > > > ---
> > > >  xen/include/public/hvm/pvdrivers.h |   12 +++++++-----
> > > >  1 file changed, 7 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/xen/include/public/hvm/pvdrivers.h
> > > b/xen/include/public/hvm/pvdrivers.h
> > > > index 4c6b705..77994d2 100644
> > > > --- a/xen/include/public/hvm/pvdrivers.h
> > > > +++ b/xen/include/public/hvm/pvdrivers.h
> > > > @@ -38,10 +38,12 @@
> > > >   * indicate a driver which is yet to be released.
> > > >   */
> > > >
> > > > -#define PVDRIVERS_PRODUCT_LIST(EACH)                         \
> > > > -        EACH("xensource-windows", 0x0001) /* Citrix */       \
> > > > -        EACH("gplpv-windows",     0x0002) /* James Harper */ \
> > > > -        EACH("linux",             0x0003)                    \
> > > > -        EACH("experimental",      0xffff)
> > > > +#define PVDRIVERS_PRODUCT_LIST(EACH)                               \
> > > > +        EACH("xensource-windows",       0x0001) /* Citrix */       \
> > > > +        EACH("gplpv-windows",           0x0002) /* James Harper */ \
> > > > +        EACH("linux",                   0x0003)                    \
> > > > +        EACH("xenserver-windows-v7.0+", 0x0004) /* Citrix */       \
> > > > +        EACH("xenserver-windows-v7.2+", 0x0005) /* Citrix */       \
> > >
> > > The unplug protocol includes
> > >         4. The drivers write a four-byte build number to IO port `0x10`.
> > > Can't you use that instead of defining a new product for each version of
> > > your drivers?
> > >
> >
> > Unfortunately I need to grandfather in 4 because it's used in
> > XenServer (and cause the patched version of QEMU therein to behave in
> > a slightly funky way). I wanted to reserve 5 because it's not been
> > used in XenServer so far and therefore has no odd semantics attached
> > to it and so I intend to use it for the newer Windows-Update-ready
> > drivers, which I don't need to be able to blacklist in the 'old' way
> > as they're designed to work with upstream QEMU where there is no
> > implementation of blacklisting.
> 
> ./hw/xen/xen_platform.c seems to have support for blacklisting in it. Or
> did you mean hw/xen/xen_pvdevice?
> 

No, I meant xen_platform; that's still the home of the fixed IO ports. From my reading of the code in xen_platform.c I don't see anything that ever sets s->drivers_blacklisted - am I missing something subtle?

> > I was originally intending to use 1, but that also has been messed
> > with in XenServer to work around some compatibility problems.
> >
> > > How does this interact with the use of the alternative platform device
> > > thing which you added? Does docs/misc/hvm-emulated-
> unplug.markdown
> > > need
> > > expanding to cover that case?
> > >
> >
> > No, I still use the traditional unplug protocol and will respect
> > blacklisting
> 
> Hrm, what is the traditional unplug protocol? Something other than
> docs/misc/hvm-emulated-unplug.markdown?
> 

That's the one I mean. XenServer has another which we don't propose to upstream.

> Assuming it is that, xen_pvdevice doesn't seem to implement any of it,
> won't the drivers therefore abort at #1?"  If the magic number doesn't
> match, the drivers don't do anything."?
> 

xen_pvdevice doesn't need to, xen_platform is always there.

> >  if anyone cares to implement it for product number 5 but, as I said,
> > I don't anticipate the need for it.
> 
> So product 5 is intended to be the same thing no matter whether you use
> xen_platform or xen_pvdevice and no matter which vendor/device ID is
> configured? You can only make this true for Citrix vendor ids I think,
> or do you intend this to be binding for everyone?
> 

The whole point of having this header file is that it is the canonical list of product codes; it should apply to everyone. That is why I'm reserving 4 and 5 - to make sure that no-one else tries to use them.

> I think that doc should be expanded to at least mention what is going on
> here, since there are a lot of reasonable options and it's not clear to
> me at least which one we are following.
> 
> > > I notice that docs/misc/hvm-emulated-unplug.markdown also says:
> > >         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.
> > > which isn't accurate any longer...
> > >
> >
> > True, but then Linux PVonHVM didn't register product number 3 either,
> > which is what led to a lot of the craziness leading to me now having
> > to register 4 and 5.
> 
> I'm not sure I follow. How does PVHVM using 3 mean that you *have* to
> reserve anything at all? I can see how given you need to register
> something it now has to be 4 etc but that seems normal not crazy.
> 

The problem was that we started using 3 in the belief that this was safe, because no-one had put any code into qemu that suggested 3 was already in use by anyone (and this header in xen did not exist). We then used the build number for product in a new way so we could blacklist drivers according to their PCI binding, only then to discover that PVonHVM linux no longer worked properly. So, we hastily moved to product code 4 with the same semantics for build number. That is why I want make sure that is reserved, and reserve 5 for future use.

  Paul

Re: [PATCH] Register PV driver product numbers 4 and 5.

[Ian Campbell]

On Thu, 2013-10-03 at 17:19 +0100, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 03 October 2013 15:33
> > To: Paul Durrant
> > Cc: xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] [PATCH] Register PV driver product numbers 4 and
> > 5.
> > 
> > On Thu, 2013-10-03 at 15:19 +0100, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > Sent: 03 October 2013 14:19
> > > > To: Paul Durrant
> > > > Cc: xen-devel@lists.xen.org
> > > > Subject: Re: [Xen-devel] [PATCH] Register PV driver product numbers 4
> > and
> > > > 5.
> > > >
> > > > On Mon, 2013-09-30 at 12:18 +0100, Paul Durrant wrote:
> > > > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > > > > ---
> > > > >  xen/include/public/hvm/pvdrivers.h |   12 +++++++-----
> > > > >  1 file changed, 7 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/xen/include/public/hvm/pvdrivers.h
> > > > b/xen/include/public/hvm/pvdrivers.h
> > > > > index 4c6b705..77994d2 100644
> > > > > --- a/xen/include/public/hvm/pvdrivers.h
> > > > > +++ b/xen/include/public/hvm/pvdrivers.h
> > > > > @@ -38,10 +38,12 @@
> > > > >   * indicate a driver which is yet to be released.
> > > > >   */
> > > > >
> > > > > -#define PVDRIVERS_PRODUCT_LIST(EACH)                         \
> > > > > -        EACH("xensource-windows", 0x0001) /* Citrix */       \
> > > > > -        EACH("gplpv-windows",     0x0002) /* James Harper */ \
> > > > > -        EACH("linux",             0x0003)                    \
> > > > > -        EACH("experimental",      0xffff)
> > > > > +#define PVDRIVERS_PRODUCT_LIST(EACH)                               \
> > > > > +        EACH("xensource-windows",       0x0001) /* Citrix */       \
> > > > > +        EACH("gplpv-windows",           0x0002) /* James Harper */ \
> > > > > +        EACH("linux",                   0x0003)                    \
> > > > > +        EACH("xenserver-windows-v7.0+", 0x0004) /* Citrix */       \
> > > > > +        EACH("xenserver-windows-v7.2+", 0x0005) /* Citrix */       \
> > > >
> > > > The unplug protocol includes
> > > >         4. The drivers write a four-byte build number to IO port `0x10`.
> > > > Can't you use that instead of defining a new product for each version of
> > > > your drivers?
> > > >
> > >
> > > Unfortunately I need to grandfather in 4 because it's used in
> > > XenServer (and cause the patched version of QEMU therein to behave in
> > > a slightly funky way). I wanted to reserve 5 because it's not been
> > > used in XenServer so far and therefore has no odd semantics attached
> > > to it and so I intend to use it for the newer Windows-Update-ready
> > > drivers, which I don't need to be able to blacklist in the 'old' way
> > > as they're designed to work with upstream QEMU where there is no
> > > implementation of blacklisting.
> > 
> > ./hw/xen/xen_platform.c seems to have support for blacklisting in it. Or
> > did you mean hw/xen/xen_pvdevice?
> > 
> 
> No, I meant xen_platform; that's still the home of the fixed IO ports.
> From my reading of the code in xen_platform.c I don't see anything
> that ever sets s->drivers_blacklisted - am I missing something subtle?

I thought you meant there was no implementation of the blacklisting
protocol itself, which there is, it just doesn't happen to actually
blacklist anything.

> > > I was originally intending to use 1, but that also has been messed
> > > with in XenServer to work around some compatibility problems.
> > >
> > > > How does this interact with the use of the alternative platform device
> > > > thing which you added? Does docs/misc/hvm-emulated-
> > unplug.markdown
> > > > need
> > > > expanding to cover that case?
> > > >
> > >
> > > No, I still use the traditional unplug protocol and will respect
> > > blacklisting
> > 
> > Hrm, what is the traditional unplug protocol? Something other than
> > docs/misc/hvm-emulated-unplug.markdown?
> > 
> 
> That's the one I mean. XenServer has another which we don't propose to upstream.
> 
> > Assuming it is that, xen_pvdevice doesn't seem to implement any of it,
> > won't the drivers therefore abort at #1?"  If the magic number doesn't
> > match, the drivers don't do anything."?
> > 
> 
> xen_pvdevice doesn't need to, xen_platform is always there.

I'm not sure I understand what you are trying to say.

How does a driver which expects the blacklist protocol work with
xen_pvdevice which doesn't implement that protocol?

Or are does a driver which works with xen_platform not work with
xen_pvdevice and vice versa? Or do the drivers have to contain code to
determine which they are running against and only do the unplug against
xen_platform?

I'm a bit surprised xen_platform doesn't implement the unplug protocol,
I thought it was just a xen_platform with parameterised vendor id etc.

> > >  if anyone cares to implement it for product number 5 but, as I said,
> > > I don't anticipate the need for it.
> > 
> > So product 5 is intended to be the same thing no matter whether you use
> > xen_platform or xen_pvdevice and no matter which vendor/device ID is
> > configured? You can only make this true for Citrix vendor ids I think,
> > or do you intend this to be binding for everyone?
> > 
> 
> The whole point of having this header file is that it is the canonical
> list of product codes;

In which namespace is my question.

Do the drivers using these 4 and 5 codes work with xen_platform and/or
xen_pvdevice?

xen_pvdevice doesn't implement the unplug protocol AFAICT, so the list
of product codes seems to be pretty irrelevant to it.

>  it should apply to everyone. That is why I'm reserving 4 and 5 - to
> make sure that no-one else tries to use them.


Ian.

Re: [PATCH] Register PV driver product numbers 4 and 5.

[Paul Durrant]

> -----Original Message-----
> 
> I'm not sure I understand what you are trying to say.
> 
> How does a driver which expects the blacklist protocol work with
> xen_pvdevice which doesn't implement that protocol?
>

It's a bit confusing, I agree. Referring back to previous threads though, all HVM systems are assumed to have the xen platform PCI device (as there is no way to turn it off if you’re using machine type xenfv), thus the fixed IO ports that implement the blacklisting protocol are assumed to always be present. Because the ports are fixed and always present the PV drivers don't have to care which device they are binding to - they talk to the same IO ports regardless.
 
> Or are does a driver which works with xen_platform not work with
> xen_pvdevice and vice versa? Or do the drivers have to contain code to
> determine which they are running against and only do the unplug against
> xen_platform?
> 
> I'm a bit surprised xen_platform doesn't implement the unplug protocol,
> I thought it was just a xen_platform with parameterised vendor id etc.
> 
> > > >  if anyone cares to implement it for product number 5 but, as I said,
> > > > I don't anticipate the need for it.
> > >
> > > So product 5 is intended to be the same thing no matter whether you use
> > > xen_platform or xen_pvdevice and no matter which vendor/device ID is
> > > configured? You can only make this true for Citrix vendor ids I think,
> > > or do you intend this to be binding for everyone?
> > >
> >
> > The whole point of having this header file is that it is the canonical
> > list of product codes;
> 
> In which namespace is my question.
> 
> Do the drivers using these 4 and 5 codes work with xen_platform and/or
> xen_pvdevice?
> 
> xen_pvdevice doesn't implement the unplug protocol AFAICT, so the list
> of product codes seems to be pretty irrelevant to it.
> 

Indeed, as I explained above the unplug protocol is controlled entirely by xen_platform and this header file refers only to that namespace.

  Paul

> >  it should apply to everyone. That is why I'm reserving 4 and 5 - to
> > make sure that no-one else tries to use them.
> 
> 
> Ian.

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

Re: [PATCH] Register PV driver product numbers 4 and 5.

[Paul Durrant]

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of Paul Durrant
> Sent: 03 October 2013 17:56
> To: Ian Campbell
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH] Register PV driver product numbers 4 and
> 5.
> 
> > -----Original Message-----
> >
> > I'm not sure I understand what you are trying to say.
> >
> > How does a driver which expects the blacklist protocol work with
> > xen_pvdevice which doesn't implement that protocol?
> >
> 
> It's a bit confusing, I agree. Referring back to previous threads though, all
> HVM systems are assumed to have the xen platform PCI device (as there is
> no way to turn it off if you’re using machine type xenfv), thus the fixed IO
> ports that implement the blacklisting protocol are assumed to always be
> present. Because the ports are fixed and always present the PV drivers don't
> have to care which device they are binding to - they talk to the same IO ports
> regardless.
> 
> > Or are does a driver which works with xen_platform not work with
> > xen_pvdevice and vice versa? Or do the drivers have to contain code to
> > determine which they are running against and only do the unplug against
> > xen_platform?
> >
> > I'm a bit surprised xen_platform doesn't implement the unplug protocol,
> > I thought it was just a xen_platform with parameterised vendor id etc.
> >
> > > > >  if anyone cares to implement it for product number 5 but, as I said,
> > > > > I don't anticipate the need for it.
> > > >
> > > > So product 5 is intended to be the same thing no matter whether you
> use
> > > > xen_platform or xen_pvdevice and no matter which vendor/device ID
> is
> > > > configured? You can only make this true for Citrix vendor ids I think,
> > > > or do you intend this to be binding for everyone?
> > > >
> > >
> > > The whole point of having this header file is that it is the canonical
> > > list of product codes;
> >
> > In which namespace is my question.
> >
> > Do the drivers using these 4 and 5 codes work with xen_platform and/or
> > xen_pvdevice?
> >
> > xen_pvdevice doesn't implement the unplug protocol AFAICT, so the list
> > of product codes seems to be pretty irrelevant to it.
> >
> 
> Indeed, as I explained above the unplug protocol is controlled entirely by
> xen_platform and this header file refers only to that namespace.
> 
>   Paul
> 
> > >  it should apply to everyone. That is why I'm reserving 4 and 5 - to
> > > make sure that no-one else tries to use them.
> >
> >
> > Ian.
> 

Ping? Do I need to add any further clarification?

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

Re: [PATCH] Register PV driver product numbers 4 and 5.

[Ian Campbell]

On Tue, 2013-10-08 at 15:53 +0100, Paul Durrant wrote:

> > It's a bit confusing, I agree. Referring back to previous threads though, all
> > HVM systems are assumed to have the xen platform PCI device (as there is
> > no way to turn it off if you’re using machine type xenfv), thus the fixed IO
> > ports that implement the blacklisting protocol are assumed to always be
> > present. Because the ports are fixed and always present the PV drivers don't
> > have to care which device they are binding to - they talk to the same IO ports
> > regardless.

That makes sense I suppose.

Can we add some words about this relationship to the docs then?

> Ping? Do I need to add any further clarification?

I thought I'd already replied but I don't see it anywhere on the list or
in my sent box, sorry.

Ian/


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

Re: [PATCH] Register PV driver product numbers 4 and 5.

[Sander Eikelenboom]

Wednesday, October 9, 2013, 10:00:53 AM, you wrote:

> On Tue, 2013-10-08 at 15:53 +0100, Paul Durrant wrote:

>> > It's a bit confusing, I agree. Referring back to previous threads though, all
>> > HVM systems are assumed to have the xen platform PCI device (as there is
>> > no way to turn it off if you’re using machine type xenfv), thus the fixed IO
>> > ports that implement the blacklisting protocol are assumed to always be
>> > present. Because the ports are fixed and always present the PV drivers don't
>> > have to care which device they are binding to - they talk to the same IO ports
>> > regardless.

Paul,

Do you by any chance know the commit that made this unconditional ?
(it used to be possible to switch it off with xen_platform_pci=0, and i'm trying to see
if the platform device and the hidden NIC (pci 00:03.0 not visible in guest lspci but it's there
(xl dmesg reports it begin generate and there is a gap in the device number
(platform 00:02.0 passthroughed device 00:04.0) has something to do with it.

The rom bar of my passthroughed device some how gets wired at first to the vga bios of the cirrus vga or stdvga.
When i disable the emulated vga (-nographic and -vga none) it is suddenly wired to the ixpe rom (of device 00:03.0).

So there is something funky going on in either hvmloader, seabios and/or qemu.
But it would be nice to rule out as much as possible.

--
Sander

> That makes sense I suppose.

> Can we add some words about this relationship to the docs then?

>> Ping? Do I need to add any further clarification?

> I thought I'd already replied but I don't see it anywhere on the list or
> in my sent box, sorry.

> Ian/





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

Re: [PATCH] Register PV driver product numbers 4 and 5.

[Paul Durrant]

> -----Original Message-----
> From: Ian Campbell
> Sent: 09 October 2013 09:01
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH] Register PV driver product numbers 4 and
> 5.
> 
> On Tue, 2013-10-08 at 15:53 +0100, Paul Durrant wrote:
> 
> > > It's a bit confusing, I agree. Referring back to previous threads though, all
> > > HVM systems are assumed to have the xen platform PCI device (as there
> is
> > > no way to turn it off if you’re using machine type xenfv), thus the fixed IO
> > > ports that implement the blacklisting protocol are assumed to always be
> > > present. Because the ports are fixed and always present the PV drivers
> don't
> > > have to care which device they are binding to - they talk to the same IO
> ports
> > > regardless.
> 
> That makes sense I suppose.
> 
> Can we add some words about this relationship to the docs then?
>

Sure. Will do.

  Paul
 
> > Ping? Do I need to add any further clarification?
> 
> I thought I'd already replied but I don't see it anywhere on the list or
> in my sent box, sorry.
> 
> Ian/

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

Re: [PATCH] Register PV driver product numbers 4 and 5.

[Paul Durrant]

> -----Original Message-----
> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> Sent: 09 October 2013 10:10
> To: Ian Campbell
> Cc: Paul Durrant; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH] Register PV driver product numbers 4 and
> 5.
> 
> 
> Wednesday, October 9, 2013, 10:00:53 AM, you wrote:
> 
> > On Tue, 2013-10-08 at 15:53 +0100, Paul Durrant wrote:
> 
> >> > It's a bit confusing, I agree. Referring back to previous threads though,
> all
> >> > HVM systems are assumed to have the xen platform PCI device (as
> there is
> >> > no way to turn it off if you’re using machine type xenfv), thus the fixed
> IO
> >> > ports that implement the blacklisting protocol are assumed to always be
> >> > present. Because the ports are fixed and always present the PV drivers
> don't
> >> > have to care which device they are binding to - they talk to the same IO
> ports
> >> > regardless.
> 
> Paul,
> 
> Do you by any chance know the commit that made this unconditional ?
> (it used to be possible to switch it off with xen_platform_pci=0, and i'm trying
> to see
> if the platform device and the hidden NIC (pci 00:03.0 not visible in guest lspci
> but it's there
> (xl dmesg reports it begin generate and there is a gap in the device number
> (platform 00:02.0 passthroughed device 00:04.0) has something to do with it.
>

Sander,

  It wasn't a commit that did this as such, it's just that no-one added the option to turn it off in upstream QEMU. I believe you can still turn it off if you're using trad QEMU.
 
> The rom bar of my passthroughed device some how gets wired at first to the
> vga bios of the cirrus vga or stdvga.
> When i disable the emulated vga (-nographic and -vga none) it is suddenly
> wired to the ixpe rom (of device 00:03.0).
> 
> So there is something funky going on in either hvmloader, seabios and/or
> qemu.

Yes, that sounds very funky.

  Paul

> But it would be nice to rule out as much as possible.
> 
> --
> Sander
> 
> > That makes sense I suppose.
> 
> > Can we add some words about this relationship to the docs then?
> 
> >> Ping? Do I need to add any further clarification?
> 
> > I thought I'd already replied but I don't see it anywhere on the list or
> > in my sent box, sorry.
> 
> > Ian/
> 
> 
> 

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

Re: [PATCH] Register PV driver product numbers 4 and 5.

[Sander Eikelenboom]

Wednesday, October 9, 2013, 12:19:38 PM, you wrote:

>> -----Original Message-----
>> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>> Sent: 09 October 2013 10:10
>> To: Ian Campbell
>> Cc: Paul Durrant; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] [PATCH] Register PV driver product numbers 4 and
>> 5.
>> 
>> 
>> Wednesday, October 9, 2013, 10:00:53 AM, you wrote:
>> 
>> > On Tue, 2013-10-08 at 15:53 +0100, Paul Durrant wrote:
>> 
>> >> > It's a bit confusing, I agree. Referring back to previous threads though,
>> all
>> >> > HVM systems are assumed to have the xen platform PCI device (as
>> there is
>> >> > no way to turn it off if you’re using machine type xenfv), thus the fixed
>> IO
>> >> > ports that implement the blacklisting protocol are assumed to always be
>> >> > present. Because the ports are fixed and always present the PV drivers
>> don't
>> >> > have to care which device they are binding to - they talk to the same IO
>> ports
>> >> > regardless.
>> 
>> Paul,
>> 
>> Do you by any chance know the commit that made this unconditional ?
>> (it used to be possible to switch it off with xen_platform_pci=0, and i'm trying
>> to see
>> if the platform device and the hidden NIC (pci 00:03.0 not visible in guest lspci
>> but it's there
>> (xl dmesg reports it begin generate and there is a gap in the device number
>> (platform 00:02.0 passthroughed device 00:04.0) has something to do with it.
>>

> Sander,

>   It wasn't a commit that did this as such, it's just that no-one added the option to turn it off in upstream QEMU. I believe you can still turn it off if you're using trad QEMU.

Hrmmm it seems the unplug of disk and nic is also unconditional then ?
Regardless if the guest os has the PV drivers ?

(using a recent guest kernel without xen pv drivers can't find it's disk and thus boot device ?)

>  
>> The rom bar of my passthroughed device some how gets wired at first to the
>> vga bios of the cirrus vga or stdvga.
>> When i disable the emulated vga (-nographic and -vga none) it is suddenly
>> wired to the ixpe rom (of device 00:03.0).
>> 
>> So there is something funky going on in either hvmloader, seabios and/or
>> qemu.

> Yes, that sounds very funky.

Yips, any reason why the PV nic is unvisible for lspci ?

>   Paul

>> But it would be nice to rule out as much as possible.
>> 
>> --
>> Sander
>> 
>> > That makes sense I suppose.
>> 
>> > Can we add some words about this relationship to the docs then?
>> 
>> >> Ping? Do I need to add any further clarification?
>> 
>> > I thought I'd already replied but I don't see it anywhere on the list or
>> > in my sent box, sorry.
>> 
>> > Ian/
>> 
>> 
>> 



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