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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
