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. Worst case we hardcode those
numbers (gasp, faint).
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.
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 maybe
$ qemu -show default-machine
$ qemu -show pci-bus
$ qemu -show me a way out
--
error compiling committee.c: too many arguments to function
--
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
