Hello!
> I'd be inclined to go with option 2, and then if any PCI
devices are
> actually used with the guest, check the capability at start time when
> we are doing auto-address assignment.
I am following the discussion, sorry for being a bit silent... Just didn't have much
to say. But
what is actually wrong with using capabilities in post-parse?
Anyway, devices do not have PCI addresses by default. They have them only if the user
explicitly
says so, to stay backwards-compatible with old guests. So, in a practical scenario the
user would
first upgrade qemu, then start adding PCI devices. And, while adding them, the user will
get PCI
controller in the description automatically.
The only hypothetical scenario i could imagine is downgrading qemu. But anyway, in this
case the
user would have to manually remove PCI devices from the domain XML.
Can anybody suggest a scenario where adding PCI in post-parse actually harms? The only
argument i
heard was: "we should not be using the QEMU capabilities when defining the XML".
But why?
Another option: add versioned 'virt' machine types to the
next qemu release
(like virt-2.5 etc.), and key libvirt enabling pci off of that.
1. virt machine (unversioned one) already has PCI.
2. qemu people don't want to have versioned "virt". I already proposed this
for GICv3 and they
strictly refused.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia