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