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
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
