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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
