Re: [PATCH 2/2] HACK: qemu: aarch64: Use virtio-pci if user specifies PCI controller

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

 



On Wed, Mar 09, 2016 at 01:40:36PM +0100, Andrea Bolognani wrote:
> On Fri, 2016-03-04 at 17:05 -0500, Laine Stump wrote:
> > > I'm not sure I fully understand all of the above, but I'll pitch
> > > in with my own proposal regardless :)
> > > 
> > > First, we make sure that
> > > 
> > >    <controller type='pci' index='0' model='pcie-root'/>
> > > 
> > > is always added automatically to the domain XML when using the
> > > mach-virt machine type. Then, if
> > > 
> > >    <controller type='pci' index='1' model='dmi-to-pci-bridge'/>
> > >    <controller type='pci' index='2' model='pci-bridge'/>
> > > 
> > > is present as well we default to virtio-pci, otherwise we use
> > > the current default of virtio-mmio. This should allow management
> > > applications, based on knowledge about the guest OS, to easily
> > > pick between the two address schemes.
> > > 
> > > Does this sound like a good idea?
> > ... or a variation of that, anyway :-)
> > 
> > What I think: If there are *any* pci controllers *beyond* pcie-root, or 
> > if there are any devices that already have a PCI address, then assign 
> > PCI addresses, else use mmio.
> 
> This sounds reasonable.
> 
> However, I'm wondering if we shouldn't be even more explicit about
> this... From libvirt's point of view we just need to agree on some
> sort of "trigger" that causes it to allocate PCI addresses instead
> of MMIO addresses, and for that purpose "any PCI controller or any
> device with a PCI address" is perfectly fine; looking at that from
> the point of view of an user, though? Not sure about it.
> 
> What about adding something like
> 
>   <preferences>
>     <preference name="defaultAddressType" value="pci"/>
>   </preferences>
> 
> to the domain XML? AFAICT libvirt doesn't have any element that
> could be used for this purpose at the moment, but maybe having a
> generic way to set domain-wide preferences could be useful in
> other situations as well?

[snip]

Looking at this mail and laine's before I really get the impression we
are over-thinking this all. The automatic address assignment by libvirt
was written such that it matched what QEMU would have done, so that we
could introduce the concept of device addressing without breaking
existing apps which didn't supply addresses. The automatic addressing
logic certainly wasn't ever intended to be able to implement arbitrary
policies.

As a general rule libvirt has always aimed to stay out of the policy
business, and focus on providing the mechanism only. So when we start
talking about adding  <preferences> to the XML this is a sure sign
that we've gone too far into trying to implement policy in libvirt.

>From the POV of being able to tell libvirt to assign PCI instead of
MMIO addresses for the virt machine, I think it suffices to have
libvirt accept a simple  <address type="pci"/> element (ie with no
bus/slot/func filled in).

If applictions care about assigning devices to specify PCI buses,
ie to distinguish between PCI & PCIe, or to pick a different bus
when there is one bus per NUMA node, then really it is time for
the application to start specifying the full <address> element
with all details, and not try to invent ever more complex policies
inside libvirt which will never deal with all application use cases.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]