[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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@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. ./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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |