On Fri, Sep 19, 2025 at 07:00:17PM +0200, Peter Krempa wrote:
> On Fri, Sep 19, 2025 at 10:34:39 -0500, Andrea Bolognani wrote:
> > On Fri, Sep 19, 2025 at 11:39:05AM +0200, Peter Krempa wrote:
> > > On Tue, Aug 19, 2025 at 18:22:34 +0200, Andrea Bolognani via Devel wrote:
> > > > +++
> > > > b/tests/qemuxmlconfdata/armv7l-versatilepb-minimal.armv7l-latest.args
> > > > @@ -26,7 +26,7 @@
> > > > XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-armv7ltest/.config \
> > > > -rtc base=utc \
> > > > -no-shutdown \
> > > > -boot strict=on \
> > > > --device '{"driver":"pci-ohci","id":"usb","bus":"pci","addr":"0x1"}' \
> > > > +-device '{"driver":"qemu-xhci","id":"usb","bus":"pci","addr":"0x1"}' \
> > >
> > > This change seems to have happened also in code paths not allowing ABI
> > > update at least according to the filename.
> >
> > It only affects domains for which a model was not picked in the past.
> > So effectively only new domains, regardless of the flags. Existing
> > domains will keep using whatever model they're configured to use.
>
> Beware that we historically considered also virDomainCreateXML
> (transient wit possibly not fully filled XML) to be compatible across
> runs. I know that we already didn't obey this in some cases but we
> should consider this every time.
Fair point. I feel that the actual impact on users is going to be
basically zero in this case, so I'm inclined to focus more on
reaching well-defined, reasonably consistent behavior across the
board that's implemented in a maintainable manner rather than
necessarily preserving the existing behavior for all niche machine
types in all niche scenarios.
> Especially in case of these limited boards the hardware you'd normally
> built in will certainly not be XHCI
I'd be fine using pci-ohci as the baseline for everything that is not
one of the "explicitly supported" machines (that is, virt across
architectures, i440fx and q35 on x86, pseries on ppc64 and
s390-ccw-virtio on s390x). That's pretty much exactly how things look
once this series has been applied.
In this case, however, I'm simply extending the existing default for
64-bit Arm machines to 32-bit ones.
I don't think it makes sense to differentiate the model based on the
number of bits - QEMU doesn't. So either we downgrade the 64-bit
machines or upgrade the 32-bit ones.
Looking at what QEMU does, the default for this machine type is
pci-ohci. So I'd say let's go with that.
--
Andrea Bolognani / Red Hat / Virtualization
