On Tue, 2009-06-16 at 15:28 +0300, Avi Kivity wrote: > On 06/16/2009 03:14 PM, Mark McLoughlin wrote: > > On Mon, 2009-06-15 at 13:12 -0500, Anthony Liguori wrote: > > > >> 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. > >> > > > > If qemu can't provide that information, then the management app does not > > have sufficient information to do the slot allocation itself. In which > > case, it must leave it up to qemu to do it. > > > > A given -M machine will have well-known open slots (since it's an ABI), > same as it has rtl8139 and ne2000 cards. If they're so obviously well-known, I don't see how the query mechanism would not be straightforward, which is the comment I was replying to. > Worst case we hardcode those numbers (gasp, faint). Maybe we can just add the open slots to the -help output. That'd be nice and clean. > >> It doesn't matter though because it's orthogonal to the current proposal. > >> > > > > It is not orthogonal to solving the actual problem at hand, though - > > i.e. how to allow management apps to provide stable PCI addresses. > > > > It's part of the solution, but hardly a difficult the most difficult part. Agree. > > This is a fine solution to the "stable guest ABI" problem ... assuming > > there's some way of querying the current default machine type. > > > > $ qemu -print-default-machine Or: $ readlink /usr/share/qemu/machine-types/pc.dt Cheers, Mark. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
