On Thu, Sep 18, 2025 at 03:04:28PM +0200, Peter Krempa wrote:
> On Tue, Aug 19, 2025 at 18:22:22 +0200, Andrea Bolognani via Devel wrote:
> > + /* Sanity check. If the machine type supports PCI, we need to reflect
> > + * that fact in the XML or other parts of the machine handling code
> > + * might misbehave */
>
> This one is a bit borderline. IMO you can have machine with no default
> PCI but the possibility to explicily add such a bus.
Can you point to a specific example? I'm not aware of any.
To the best of my knowledge, all machines that are PCI-capable come
with a root PCI controller out of the gate.
There is no QEMU device corresponding to the root PCI controller
either, so I don't know how you would even go about adding it if it
were opt-in. Perhaps a machine type flag but again, I'm not aware of
that actually being a thing.
> > + if (qemuDomainSupportsPCI(def) &&
> > + !addPCIRoot &&
> > + !addPCIeRoot) {
> > + virReportError(VIR_ERR_INTERNAL_ERROR,
> > + _("Machine type '%1$s' supports PCI but no PCI
> > controller added"),
> > + def->os.machine);
> > + return -1;
> > + }
> > +
> > + /* Sanity check. USB controllers are PCI devices, so asking for a
> > + * USB controller to be added but not for a PCI(e) root to be
> > + * added at the same time is likely an oversight */
>
> I'm fairly sure there are non-PCI USB controllers so this one is
> definitely false. It's just that libvirt supports only USB controllers
> which are on PCI.
>
> IMO this assumption should be validated with the USB controller itself.
I'm not aware of any non-PCI USB controller out there, certainly not
in QEMU. Can you point to one?
--
Andrea Bolognani / Red Hat / Virtualization
