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

Martin Kletzander mkletzan at redhat.com
Tue Oct 25 12:10:37 UTC 2016


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

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

>-- 
>Andrea Bolognani / Red Hat / Virtualization
-------------- 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/a929822e/attachment-0001.sig>


More information about the libvir-list mailing list