On Tue, Aug 19, 2025 at 18:22:28 +0200, Andrea Bolognani via Devel wrote: > Extract the logic from qemuDomainControllerDefPostParse() to > a dedicated helper. The behavior is unchanged. > > Signed-off-by: Andrea Bolognani <abolo...@redhat.com> > --- > src/qemu/qemu_domain.c | 82 +++++++++++++++++++++++++++++++++++++++ > src/qemu/qemu_domain.h | 3 ++ > src/qemu/qemu_postparse.c | 51 +----------------------- > 3 files changed, 86 insertions(+), 50 deletions(-) > > diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c > index 186e36da03..f03624eda8 100644 > --- a/src/qemu/qemu_domain.c > +++ b/src/qemu/qemu_domain.c > @@ -4294,6 +4294,88 @@ qemuDomainDefaultPanicModel(const virDomainDef *def) > } > > > +/** > + * qemuDomainDefaultUSBControllerModel: > + * @def: domain definition > + * @qemuCaps: QEMU capabilities, or NULL > + * @parseFlags: parse flags > + * > + * Choose a reasonable model to use for a USB controller where a > + * specific one hasn't been provided by the user. > + * > + * The choice is based on a number of factors, including the guest's > + * architecture and machine type. @qemuCaps, if provided, might be > + * taken into consideration too.
This statement is a bit misleading. In cases where qemuCaps is NULL you must not be doing any decisions that depend on the caps that wouldn't be undone by another run of this function with caps present. In cases where the caps for given qemu are not present and the XML parsed is one of the persistent configs loaded from disk, the postparse code will be re-tried at next startup attempt where it has to be present for the VM to work. If you'd pick an incorrect model based on missing caps that'd be remembered and not fixed on startup, but it would behave differently if the caps are present.
