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.
> 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.
> >>> I'm not at all arguing against pci_addr. I'm arguing about how
> >>> libvirt should use it with respect to the "genesis" use-case where
> >>> libvirt has no specific reason to choose one PCI slot over another.
> >>> In that case, I'm merely advocating that we want to let QEMU make the
> >>> decision.
> >>>
> >> However this may end up, isn't it offtopic? Whatever we do we have to
> >> support both pci_addr= and default placement, so we can push this
> >> discussion to livirt-devel and bid them godspeed.
> >>
> >
> > Presumably you're not proposing that qemu-devel completely ignore the
> > typical requirements of management apps?
> >
>
> This is a happy case where the current proposals allow both usages to
> occur. Which one libvirt chooses it up to it.
>
> To summarize, I think we have:
>
> 1) Introduce addressing to all host device configurations
> - Either in the canonical form "pci_addr=bus:dev.fn or target=3,lun=1"
> or in flattened form "addr=bus:dev.fn or addr=target.lun". I prefer the
> later form but I think either would be acceptable.
That helps, but it's not enough on its own.
The management app needs to figure out what addresses to pass either by:
a) Initially allowing qemu to do the address allocation, and
thereafter using those addresses - this requires some way to query
the addresses of devices
or b) Doing the initial address allocation itself - this requires some
way to query what slots are available.
> 2) Whenever the default machine type changes in a guest-visible way,
> introduce a new machine type
> - Use explicit versions in name: pc-v1, pc-v2 or use more descriptive
> names pc-with-usb
> - Easily transitions to device config files
To be clear - you're not proposing this is a solution to the "stable PCI
addresses" problem, are you? The main requirement is for the addresses
to stay stable even if the user adds/removes other devices.
This is a fine solution to the "stable guest ABI" problem ... assuming
there's some way of querying the current default machine type.
Cheers,
Mark.
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
