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

Reply via email to