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
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list