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

[Anthony Liguori]

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