The XenServer 6.1+ Citrix Windows PV bus driver binds to a new version
of the Xen platform device (since the newer driver set cannot co-exist
with previous drivers which bind to the existing "xen-platform" type
of
device). This patch introduces a new "xen-platform-2" device type with
the appropriate device_id and revision.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
---
hw/xen/xen_platform.c | 75 ++++++++++++++++++++++++++++++++++++++--------
include/hw/pci/pci_ids.h | 1 +
2 files changed, 63 insertions(+), 13 deletions(-)
diff --git a/hw/xen/xen_platform.c b/hw/xen/xen_platform.c
index b6c6793..6edb850 100644
--- a/hw/xen/xen_platform.c
+++ b/hw/xen/xen_platform.c
@@ -48,6 +48,20 @@
#define PFFLAG_ROM_LOCK 1 /* Sets whether ROM memory area is RW or RO */
+typedef struct {
+ const char *name;
+ const char *desc;
+ uint16_t device_id;
+ uint8_t revision;
+ uint16_t subsystem_vendor_id;
+ uint16_t subsystem_id;
+} PCIXenPlatformDeviceInfo;
+
+typedef struct PCIXenPlatformDeviceClass {
+ PCIDeviceClass parent_class;
+ PCIXenPlatformDeviceInfo info;
+} PCIXenPlatformDeviceClass;
+
typedef struct PCIXenPlatformState {
PCIDevice pci_dev;
MemoryRegion fixed_io;
@@ -372,8 +386,13 @@ static const VMStateDescription vmstate_xen_platform = {
static int xen_platform_initfn(PCIDevice *dev)
{
PCIXenPlatformState *d = DO_UPCAST(PCIXenPlatformState, pci_dev, dev);
+ PCIDeviceClass *k = PCI_DEVICE_GET_CLASS(dev);
+ __attribute__((unused)) PCIXenPlatformDeviceClass *u;
uint8_t *pci_conf;
+ u = container_of(k, PCIXenPlatformDeviceClass, parent_class);
+ DPRINTF("initializing %s\n", u->info.name);
+
pci_conf = d->pci_dev.config;
pci_set_word(pci_conf + PCI_COMMAND, PCI_COMMAND_IO | PCI_COMMAND_MEMORY);
@@ -402,33 +421,63 @@ static void platform_reset(DeviceState *dev)
platform_fixed_ioport_reset(s);
}
+static PCIXenPlatformDeviceInfo platform_devices[] = {
+ {
+ .name = "xen-platform",
+ .desc = "XEN platform pci device (version 1)",
+ .device_id = PCI_DEVICE_ID_XEN_PLATFORM,
+ .revision = 1,
+ .subsystem_vendor_id = PCI_VENDOR_ID_XEN,
+ .subsystem_id = PCI_DEVICE_ID_XEN_PLATFORM,
+ }, {
+ .name = "xen-platform-2",
+ .desc = "XEN platform pci device (version 2)",
+ .device_id = PCI_DEVICE_ID_XEN_PLATFORM_V2,
+ .revision = 2,
+ .subsystem_vendor_id = PCI_VENDOR_ID_XEN,
+ .subsystem_id = PCI_DEVICE_ID_XEN_PLATFORM_V2,
+ }
+};
+
static void xen_platform_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+ PCIXenPlatformDeviceInfo *info = data;
+ PCIXenPlatformDeviceClass *u;
+
+ u = container_of(k, PCIXenPlatformDeviceClass, parent_class);
k->init = xen_platform_initfn;
k->vendor_id = PCI_VENDOR_ID_XEN;
- k->device_id = PCI_DEVICE_ID_XEN_PLATFORM;
+ k->device_id = info->device_id;
k->class_id = PCI_CLASS_OTHERS << 8 | 0x80;
- k->subsystem_vendor_id = PCI_VENDOR_ID_XEN;
- k->subsystem_id = PCI_DEVICE_ID_XEN_PLATFORM;
- k->revision = 1;
- dc->desc = "XEN platform pci device";
+ k->subsystem_vendor_id = info->subsystem_vendor_id;
+ k->subsystem_id = info->subsystem_id;
+ k->revision = info->revision;
+ dc->desc = info->desc;
dc->reset = platform_reset;
dc->vmsd = &vmstate_xen_platform;
+ u->info = *info;
}
-static const TypeInfo xen_platform_info = {
- .name = "xen-platform",
- .parent = TYPE_PCI_DEVICE,
- .instance_size = sizeof(PCIXenPlatformState),
- .class_init = xen_platform_class_init,
-};
-
static void xen_platform_register_types(void)
{
- type_register_static(&xen_platform_info);
+ TypeInfo type_info = {
+ .parent = TYPE_PCI_DEVICE,
+ .instance_size = sizeof(PCIXenPlatformState),
+ .class_size = sizeof(PCIXenPlatformDeviceClass),
+ .class_init = xen_platform_class_init,
+ };
+ int i;
+ for (i = 0; i < ARRAY_SIZE(platform_devices); i++) {
+ PCIXenPlatformDeviceInfo *info = &platform_devices[i];
+
+ type_info.name = info->name;
+ type_info.class_data = info;
+
+ type_register(&type_info);
+ }
}
type_init(xen_platform_register_types)
diff --git a/include/hw/pci/pci_ids.h b/include/hw/pci/pci_ids.h
index d8dc2f1..2039fba 100644
--- a/include/hw/pci/pci_ids.h
+++ b/include/hw/pci/pci_ids.h
@@ -144,6 +144,7 @@
#define PCI_VENDOR_ID_XEN 0x5853
#define PCI_DEVICE_ID_XEN_PLATFORM 0x0001
+#define PCI_DEVICE_ID_XEN_PLATFORM_V2 0x0002
#define PCI_VENDOR_ID_NEC 0x1033
#define PCI_DEVICE_ID_NEC_UPD720200 0x0194
--
1.7.10.4
On Wed, 2013-06-19 at 10:32 +0100, Paul Durrant wrote:> The XenServer 6.1+ Citrix Windows PV bus driver binds to a new version > of the Xen platform device (since the newer driver set cannot co-exist > with previous drivers which bind to the existing "xen-platform" type of > device). This patch introduces a new "xen-platform-2" device type with > the appropriate device_id and revision.What is the difference between these two devices? Ian.
> -----Original Message----- > From: Ian Campbell > Sent: 19 June 2013 10:42 > To: Paul Durrant > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org > Subject: Re: [Xen-devel] [PATCH] Add Xen platform PCI device version 2. > > On Wed, 2013-06-19 at 10:32 +0100, Paul Durrant wrote: > > The XenServer 6.1+ Citrix Windows PV bus driver binds to a new version > > of the Xen platform device (since the newer driver set cannot co-exist > > with previous drivers which bind to the existing "xen-platform" type of > > device). This patch introduces a new "xen-platform-2" device type with > > the appropriate device_id and revision. > > What is the difference between these two devices? >As the comment implies, the device_id (2 rather than 1) and the revision (2 rather than 1). Paul
On Wed, 2013-06-19 at 10:43 +0100, Paul Durrant wrote:> > -----Original Message----- > > From: Ian Campbell > > Sent: 19 June 2013 10:42 > > To: Paul Durrant > > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org > > Subject: Re: [Xen-devel] [PATCH] Add Xen platform PCI device version 2. > > > > On Wed, 2013-06-19 at 10:32 +0100, Paul Durrant wrote: > > > The XenServer 6.1+ Citrix Windows PV bus driver binds to a new version > > > of the Xen platform device (since the newer driver set cannot co-exist > > > with previous drivers which bind to the existing "xen-platform" type of > > > device). This patch introduces a new "xen-platform-2" device type with > > > the appropriate device_id and revision. > > > > What is the difference between these two devices? > > > > As the comment implies, the device_id (2 rather than 1) and the revision (2 rather than 1).So what is the point of it? Changing these IDs won''t work for any other existing PV drivers, it will break the Linux PVHVM ones and the BSD ones etc. We obviously can''t say to users "Are you running Windows and are you running PV drivers >= X.Y, if so set lever A to position B, otherwise if you are running some other OS or an earlier version of the Windows PV driver set it to position A". It sounds to me as if this is a hack to workaround some shortcoming of the Windows driver model. If this is the case then I''m afraid you are going to have to find a way to deal with this from within Windows and/or your drivers. Failing that then I think you''ll just have to document an upgrade path for the users of your older drivers. Pushing the pain onto the entire world is just not the right way to go about this. Ian.
> -----Original Message----- > From: Ian Campbell > Sent: 19 June 2013 11:08 > To: Paul Durrant > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org > Subject: Re: [Xen-devel] [PATCH] Add Xen platform PCI device version 2. > > On Wed, 2013-06-19 at 10:43 +0100, Paul Durrant wrote: > > > -----Original Message----- > > > From: Ian Campbell > > > Sent: 19 June 2013 10:42 > > > To: Paul Durrant > > > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org > > > Subject: Re: [Xen-devel] [PATCH] Add Xen platform PCI device version 2. > > > > > > On Wed, 2013-06-19 at 10:32 +0100, Paul Durrant wrote: > > > > The XenServer 6.1+ Citrix Windows PV bus driver binds to a new version > > > > of the Xen platform device (since the newer driver set cannot co-exist > > > > with previous drivers which bind to the existing "xen-platform" type of > > > > device). This patch introduces a new "xen-platform-2" device type with > > > > the appropriate device_id and revision. > > > > > > What is the difference between these two devices? > > > > > > > As the comment implies, the device_id (2 rather than 1) and the revision (2 > rather than 1). > > So what is the point of it? > > Changing these IDs won''t work for any other existing PV drivers, it will > break the Linux PVHVM ones and the BSD ones etc. > > We obviously can''t say to users "Are you running Windows and are you > running PV drivers >= X.Y, if so set lever A to position B, otherwise if > you are running some other OS or an earlier version of the Windows PV > driver set it to position A". >Why not? The device can be chosen on a per-VM basis.> It sounds to me as if this is a hack to workaround some shortcoming of > the Windows driver model. If this is the case then I''m afraid you are > going to have to find a way to deal with this from within Windows and/or > your drivers. Failing that then I think you''ll just have to document an > upgrade path for the users of your older drivers. Pushing the pain onto > the entire world is just not the right way to go about this. >After many months of worrying about this I had to conclude that there really is no way round this. If we bind newer drivers to the old device id and then hope to push them to Windows Update; much chaos, pain and anguish would occur. The only option is a new device. Is it such a bad idea to be able to support multiple HVM VM configurations at the same time? Paul
At 11:07 +0100 on 19 Jun (1371640052), Ian Campbell wrote:> On Wed, 2013-06-19 at 10:43 +0100, Paul Durrant wrote: > > > -----Original Message----- > > > From: Ian Campbell > > > Sent: 19 June 2013 10:42 > > > To: Paul Durrant > > > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org > > > Subject: Re: [Xen-devel] [PATCH] Add Xen platform PCI device version 2. > > > > > > On Wed, 2013-06-19 at 10:32 +0100, Paul Durrant wrote: > > > > The XenServer 6.1+ Citrix Windows PV bus driver binds to a new version > > > > of the Xen platform device (since the newer driver set cannot co-exist > > > > with previous drivers which bind to the existing "xen-platform" type of > > > > device). This patch introduces a new "xen-platform-2" device type with > > > > the appropriate device_id and revision. > > We obviously can''t say to users "Are you running Windows and are you > running PV drivers >= X.Y, if so set lever A to position B, otherwise if > you are running some other OS or an earlier version of the Windows PV > driver set it to position A".Agreed - that''s a horrible interface, and an egregious layer violation. The VM''s admin should be able to install/upgrade software without involving the host admin. Can you explain a bit more about why this is needed? Presumably ''real'' device manufacturers can ship new versions of their drivers through Windows Update without needing to rev their hardware or get the user to change BIOS settings. Tim.
On Wed, 2013-06-19 at 11:13 +0100, Paul Durrant wrote:> > -----Original Message----- > > From: Ian Campbell > > Sent: 19 June 2013 11:08 > > To: Paul Durrant > > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org > > Subject: Re: [Xen-devel] [PATCH] Add Xen platform PCI device version 2. > > > > On Wed, 2013-06-19 at 10:43 +0100, Paul Durrant wrote: > > > > -----Original Message----- > > > > From: Ian Campbell > > > > Sent: 19 June 2013 10:42 > > > > To: Paul Durrant > > > > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org > > > > Subject: Re: [Xen-devel] [PATCH] Add Xen platform PCI device version 2. > > > > > > > > On Wed, 2013-06-19 at 10:32 +0100, Paul Durrant wrote: > > > > > The XenServer 6.1+ Citrix Windows PV bus driver binds to a new version > > > > > of the Xen platform device (since the newer driver set cannot co-exist > > > > > with previous drivers which bind to the existing "xen-platform" type of > > > > > device). This patch introduces a new "xen-platform-2" device type with > > > > > the appropriate device_id and revision. > > > > > > > > What is the difference between these two devices? > > > > > > > > > > As the comment implies, the device_id (2 rather than 1) and the revision (2 > > rather than 1). > > > > So what is the point of it? > > > > Changing these IDs won''t work for any other existing PV drivers, it will > > break the Linux PVHVM ones and the BSD ones etc. > > > > We obviously can''t say to users "Are you running Windows and are you > > running PV drivers >= X.Y, if so set lever A to position B, otherwise if > > you are running some other OS or an earlier version of the Windows PV > > driver set it to position A". > > > > Why not? The device can be chosen on a per-VM basis.Pushing this decision onto the users is not the right design IMHO.> > It sounds to me as if this is a hack to workaround some shortcoming of > > the Windows driver model. If this is the case then I''m afraid you are > > going to have to find a way to deal with this from within Windows and/or > > your drivers. Failing that then I think you''ll just have to document an > > upgrade path for the users of your older drivers. Pushing the pain onto > > the entire world is just not the right way to go about this. > > > > After many months of worrying about this I had to conclude that there really is no way round this.Then it''ll have to be documentation, "remove these old drivers before upgrading or enabling Windows update". Perhaps blacklisting the old drivers via the I/O port protocol might help, depending on how Windows reacts.> Is it such a bad idea to be able to support multiple HVM VM > configurations at the same time?This isn''t a new configuration, it is exactly the same as the old configuration except it happens to trigger different behaviour in some particular OSes driver loading code. Sorry, I don''t think this approach is going to fly. Ian.
> > > -----Original Message----- > > From: Ian Campbell > > Sent: 19 June 2013 10:42 > > To: Paul Durrant > > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org > > Subject: Re: [Xen-devel] [PATCH] Add Xen platform PCI device version 2. > > > > On Wed, 2013-06-19 at 10:32 +0100, Paul Durrant wrote: > > > The XenServer 6.1+ Citrix Windows PV bus driver binds to a new version > > > of the Xen platform device (since the newer driver set cannot co-exist > > > with previous drivers which bind to the existing "xen-platform" type of > > > device). This patch introduces a new "xen-platform-2" device type with > > > the appropriate device_id and revision. > > > > What is the difference between these two devices? > > > > As the comment implies, the device_id (2 rather than 1) and the revision (2 > rather than 1). >Are the new drivers not backwards compatible? Do any of the new driver names conflict with the old names? If not and if the bus driver in turn enumerates devices with different names than the old then the two should be able to exist side-by-side with only one being active depending on what the vm is configured with. James
> -----Original Message----- > From: James Harper [mailto:james.harper@bendigoit.com.au] > Sent: 19 June 2013 11:55 > To: Paul Durrant; Ian Campbell > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org > Subject: RE: [Xen-devel] [PATCH] Add Xen platform PCI device version 2. > > > > > > -----Original Message----- > > > From: Ian Campbell > > > Sent: 19 June 2013 10:42 > > > To: Paul Durrant > > > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org > > > Subject: Re: [Xen-devel] [PATCH] Add Xen platform PCI device version 2. > > > > > > On Wed, 2013-06-19 at 10:32 +0100, Paul Durrant wrote: > > > > The XenServer 6.1+ Citrix Windows PV bus driver binds to a new version > > > > of the Xen platform device (since the newer driver set cannot co-exist > > > > with previous drivers which bind to the existing "xen-platform" type of > > > > device). This patch introduces a new "xen-platform-2" device type with > > > > the appropriate device_id and revision. > > > > > > What is the difference between these two devices? > > > > > > > As the comment implies, the device_id (2 rather than 1) and the revision (2 > > rather than 1). > > > > Are the new drivers not backwards compatible? > > Do any of the new driver names conflict with the old names? If not and if the > bus driver in turn enumerates devices with different names than the old > then the two should be able to exist side-by-side with only one being active > depending on what the vm is configured with. >The problem is that the old Citrix PV drivers bind their version of xenvbd directly to the platform device (id=1). The new PV drivers bind their xenbus driver to their platform device, because to go onto Windows Update you cannot have an installer and therefore cannot bind to a root enumerated node. Now, if I post a version of xenbus onto Windows Update that binds to id=1 then I cannot prevent VMs installed with the old PV drivers from downloading the new version of xenbus and using that (since it is newer) in preference to their version of xenvbd. The result would then be a BSOD 0x7B after reboot because the system disk has vanished. The issue going forward is that the only way of controlling driver download from Windows Update is by OS version and device binding. A PCI device binding only consists of vendor id, device id, subsystem vendor id, subsystem device id and revision. So if we want to control which version of the PV bus driver is applied to a VM, for a given OS, then we must vary one of those things. Paul
> -----Original Message----- > From: James Harper [mailto:james.harper@bendigoit.com.au] > Sent: 19 June 2013 11:55 > To: Paul Durrant; Ian Campbell > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org > Subject: RE: [Xen-devel] [PATCH] Add Xen platform PCI device version 2. > > > > > > -----Original Message----- > > > From: Ian Campbell > > > Sent: 19 June 2013 10:42 > > > To: Paul Durrant > > > Cc: qemu-devel@nongnu.org; xen-devel@lists.xen.org > > > Subject: Re: [Xen-devel] [PATCH] Add Xen platform PCI device version 2. > > > > > > On Wed, 2013-06-19 at 10:32 +0100, Paul Durrant wrote: > > > > The XenServer 6.1+ Citrix Windows PV bus driver binds to a new version > > > > of the Xen platform device (since the newer driver set cannot co-exist > > > > with previous drivers which bind to the existing "xen-platform" type of > > > > device). This patch introduces a new "xen-platform-2" device type with > > > > the appropriate device_id and revision. > > > > > > What is the difference between these two devices? > > > > > > > As the comment implies, the device_id (2 rather than 1) and the revision (2 > > rather than 1). > > > > Are the new drivers not backwards compatible? >No, the new drivers are not backward compatible (as I''ve explained in other mails) because of the way the old ones used the PCI device. It was an unfortunate choice but it was made many years ago - probably for good reasons at the time - and we now have to live with it. Paul> Do any of the new driver names conflict with the old names? If not and if the > bus driver in turn enumerates devices with different names than the old > then the two should be able to exist side-by-side with only one being active > depending on what the vm is configured with. > > James
At 11:23 +0000 on 19 Jun (1371641017), Paul Durrant wrote:> The problem is that the old Citrix PV drivers bind their version of > xenvbd directly to the platform device (id=1). The new PV drivers bind > their xenbus driver to their platform device, because to go onto > Windows Update you cannot have an installer and therefore cannot bind > to a root enumerated node. Now, if I post a version of xenbus onto > Windows Update that binds to id=1 then I cannot prevent VMs installed > with the old PV drivers from downloading the new version of xenbus and > using that (since it is newer)Is there room in the versioning to make sure that the drivers you push via Windows Update are always ''older'' than any other PV drivers currently in circulation? Tim.
> -----Original Message----- > From: Tim Deegan [mailto:tim@xen.org] > Sent: 19 June 2013 16:46 > To: Paul Durrant > Cc: James Harper; Ian Campbell; qemu-devel@nongnu.org; xen- > devel@lists.xen.org > Subject: Re: [Xen-devel] [PATCH] Add Xen platform PCI device version 2. > > At 11:23 +0000 on 19 Jun (1371641017), Paul Durrant wrote: > > The problem is that the old Citrix PV drivers bind their version of > > xenvbd directly to the platform device (id=1). The new PV drivers bind > > their xenbus driver to their platform device, because to go onto > > Windows Update you cannot have an installer and therefore cannot bind > > to a root enumerated node. Now, if I post a version of xenbus onto > > Windows Update that binds to id=1 then I cannot prevent VMs installed > > with the old PV drivers from downloading the new version of xenbus and > > using that (since it is newer) > > Is there room in the versioning to make sure that the drivers you push > via Windows Update are always ''older'' than any other PV drivers > currently in circulation? >The scoring rules are quite complex and I have a feeling that Windows will always select a newer (by date) version of a driver. I''d need to check. Paul
Il 19/06/2013 13:31, Paul Durrant ha scritto:> This is model we have followed in XenServer: the platform device > represents ''the set of PV drivers'' and therefore to ship a new and > non-backwards-compatible set of PV drivers we incremented the > platform device id.But what is exactly the incompatibility about? Paolo