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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Ian Campbell
> Sent: 03 October 2013 14:19
> To: Paul Durrant
> Cc: xen-devel@xxxxxxxxxxxxx
> 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@xxxxxxxxxx>
> > ---
> >  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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel