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

Attachment: signature.asc
Description: Digital signature

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

Reply via email to