[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13]

From: Avi Kivity
Subject: Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities]
Date: Tue, 16 Jun 2009 15:28:21 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]