On Mon, 2009-06-15 at 18:05 +0300, Avi Kivity wrote: > On 06/15/2009 05:24 PM, Anthony Liguori wrote: > > Dor Laor wrote: > >> Libvirt does not support r2d. I hope it won't start to support it. > > > > It supports mips, sparc, and ppc machines now. I don't see why it > > wouldn't support r2d. For ppcemb, I expect this same problem to > > occur. This sort of restriction is going to be common with embedded > > boards. > > I expect these restrictions will have to be known by the management > application. Otherwise the users will try invalid configurations only > to receive errors when they launch them. GUIs exist to guide users, not > as an inefficient means of trial-and-error. 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 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? You can push the discussion to libvirt-devel, and the conclusion would most likely be: "We can do slot allocation if you provide us with a way to query free slots, or we can use qemu's default allocation if you provide us a way to query the allocation. We'd prefer the default allocation problem, but we don't really care. Both require about the same amount of work for us." libvirt was only mentioned in this thread as a concrete example of how the suggested solutions would actually be used by management apps. Cheers, Mark. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
