[libvirt] [RFC] qemu: Use virtio-pci by default for mach-virt guests

[Pavel Hrdina]

On Tue, Oct 25, 2016 at 02:10:37PM +0200, Martin Kletzander wrote:
> On Mon, Oct 24, 2016 at 06:24:07PM +0200, Andrea Bolognani wrote:
> >On Mon, 2016-10-24 at 17:47 +0200, Pavel Hrdina wrote:
> >> > > I like that this makes pci truly the default in a simple manner, but 
> >> > > still allows switching back to mmio if necessary. On the other hand, it 
> >> > > puts the potential "switch" to decide whether or not to use mmio for all 
> >> > > devices down into the config of a single device, which is a bit weird to 
> >> > > explain. (On the other hand, how often will mmio be used in the future? 
> >> > > Maybe it doesn't matter if it's weird to explain...)
> >> > 
> >> > We really want to push for virtio-pci going forward as it has
> >> > a number of advantages, but there are still legacy guest OSs
> >> > out there that don't support virtio-pci at all yet we still
> >> > want to be able to run.
> >> 
> >> Changing the default is usually a tricky part and may break some users.
> >> I'm not sure that this will save the need to adapt management applications
> >> and users.  They will have to adapt in both cases to support legacy and
> >> new OSes based on libosinfo or another tool/database.  If we make virtio-pci
> >> the default one, which I think is the way it should be used, they will have
> >> to make sure that with new libvirt for the same OS they will fallback
> >> to virtio-mmio.
> >> 
> >> From what I can remember we've never done such change of default device
> >> model or default address and we always left it no management application
> >> or user to change the default to better model.  In case of management
> >> applications it's not an issue because they will make sure that the best
> >> device models and device address are used.
> >> 
> >> I'm not against changing the default to virtio-pci, but we may break
> >> things for some users and management tools like virt-manager unless they
> >> will adapt to this change.
> >
> >You raise very good points, thanks for your input! :)
> >
> >AFAICT the only use case that we'd risk breaking is installing
> >a legacy guest OS that doesn't support virtio-pci without
> >requiring the user to explicitly ask for virtio-mmio addresses.
> >
> 
> And that is only for new installs (just if someone misses that you said
> "installs").

Yes it will break only new installs.

> >Once libosinfo has learned about this, and virt-manager has
> >been updated to query libosinfo and switch to virtio-mmio
> >automatically if required, would you be okay with this change?
> >
> >I think for aarch64 we're still in a phase where we can afford
> >to take some tradeoffs when it comes to compatibility, if
> >they're properly motivated: in this specific case, seeing as
> >basic stuff like device hotplug has simply never worked for
> >virtio-mmio, I'm fairly confident nobody will want to stick
> >with virtio-mmio for very long now that virtio-pci is finally
> >viable.
> >
> 
> And I feel like we can change defaults like that, especially with new
> installs, that's why we save the generated info in the XMLs.  If we were
> not able to change the defaults, we would not be able to add *anything*
> to the command line by default.  And, yes, aarch64 is still in its
> diapers, so I, too, feel like we have even more leeway in such scenarios.

I agree that we can change it.  It was just to make a not that the management
application will have to update itself in any case to adapt to new libvirt.

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20161025/8d9588b6/attachment-0001.sig>