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@xxxxxxxxxx> > --- > 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. _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
