On Wed, Feb 14, 2024 at 18:11:16 +0100, Andrea Bolognani wrote:
When support for s390x was introduced in libvirt, it naturally
followed the conventions established at the time for x86, which
were to have a USB controller added by default.
Later, in 2013, commit 3a82f628a964 made the default USB
controller model for s390x VIR_DOMAIN_CONTROLLER_MODEL_USB_NONE,
effectively overriding the architecture-independent default.
However, an exception was carved out at the time: if the USB
controller had an address assigned to it, then it would be left
alone.
A couple of years later, commit 09ab9dcc85ec changed things
again in two ways: for starters, libvirt would no longer
automatically attempt to add a USB controller to newly-defined
s390x guests; moreover, the command line generator was changed
so that the legacy USB controller (-usb) would never be used
on s390x.
In other words, unless a model name is explicitly provided for
the USB controller, which is something that only actually works
when using a recent QEMU version (see commit f9ed4d385ab8),
s390x guests will never have USB controllers attached to them.
Remove the exception carved out a decade ago and always
reflect this fact accurately in the guest XML.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
src/qemu/qemu_domain.c | 14 +++++++++-----
.../qemuhotplug-base-ccw-live+ccw-virtio.xml | 5 +----
...live-with-2-ccw-virtio+ccw-virtio-1-reverse.xml | 5 +----
...qemuhotplug-base-ccw-live-with-2-ccw-virtio.xml | 5 +----
...-live-with-ccw-virtio+ccw-virtio-2-explicit.xml | 5 +----
...-base-ccw-live-with-ccw-virtio+ccw-virtio-2.xml | 5 +----
.../qemuhotplug-base-ccw-live-with-ccw-virtio.xml | 5 +----
.../qemuhotplug-base-ccw-live.xml | 5 +----
.../s390-usb-address.s390x-latest.xml | 6 +-----
9 files changed, 17 insertions(+), 38 deletions(-)
[...]
@@ -5698,6 +5696,12 @@
qemuDomainControllerDefPostParse(virDomainControllerDef *cont,
cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_NEC_XHCI;
}
}
+
+ /* Make sure the 'none' USB controller doesn't have an address
+ * associated with it, as that would trip up later checks */
+ if (cont->model == VIR_DOMAIN_CONTROLLER_MODEL_USB_NONE)
+ cont->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE;
One thing I'm slightly unsure about is whether the removal of address
won't have effect on generation of other addresses and thus in certain
very weird situations could trip up the virDomainDefCheckABIStability check.
Since the usb controller itself was never seen by the guest ABI that
part will be okay, but not reserving the address for it could cause
issues.
Now for migration this shouldn't be a problem unless somebody is passing
very weird migration XMLs.
For new VMs it can theoretically cause re-ordering of devices on the PCI
bus.