Mark McLoughlin wrote: > So long as the restrictions would be known to the management app via > some "what slots are available" mechanism in qemu, that sounds fine. > I'm not sure a "what slots are available" mechanism is as straight forward as has been claimed. It doesn't matter though because it's orthogonal to the current proposal. >>> I'm not at all arguing against pci_addr. I'm arguing about how >>> libvirt should use it with respect to the "genesis" use-case where >>> libvirt has no specific reason to choose one PCI slot over another. >>> In that case, I'm merely advocating that we want to let QEMU make the >>> decision. >>> >> However this may end up, isn't it offtopic? Whatever we do we have to >> support both pci_addr= and default placement, so we can push this >> discussion to livirt-devel and bid them godspeed. >> > > Presumably you're not proposing that qemu-devel completely ignore the > typical requirements of management apps? > This is a happy case where the current proposals allow both usages to occur. Which one libvirt chooses it up to it. To summarize, I think we have: 1) Introduce addressing to all host device configurations - Either in the canonical form "pci_addr=bus:dev.fn or target=3,lun=1" or in flattened form "addr=bus:dev.fn or addr=target.lun". I prefer the later form but I think either would be acceptable. 2) Whenever the default machine type changes in a guest-visible way, introduce a new machine type - Use explicit versions in name: pc-v1, pc-v2 or use more descriptive names pc-with-usb - Easily transitions to device config files Regards, Anthony Liguori _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
