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

Anthony Liguori
2009-06-15T18:12:38Z

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. It doesn't matter though because it's
orthogonal to the current proposal.

>>> 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.

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

Regards,

Anthony Liguori