Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities]

Mark McLoughlin
2009-06-16T12:42:03Z

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.