On Wed, Jan 17, 2024 at 01:59:57PM +0100, Peter Krempa wrote: > On Wed, Jan 17, 2024 at 10:54:48 +0100, Andrea Bolognani wrote: > > Outside of x86, where we need to try pretty hard to pick hardware > > that obsolete operating systems might be able to use, and Arm, > > where some of the less virtualization-friendly machine types have > > their own specific default, the sensible choice is virtio-net. > > > > This is even more true for any architecture that's going to be > > introduced in the future, as recent experience has shown that > > they will be developed with virtualization in mind and use > > virtio as extensively as possible. > > > > Note that the default for ppc64 is changed as part of this. > > That's technically a breaking change, but it should be safe to > > apply since > > > > * it doesn't affect existing guests; > > * virt-manager already prefers virtio-net anyway. > > > > rtl8139 was a pretty bad default for the architecture in the > > first place, which was only applied accidentally due to its > > existing status as default for x86. > > IMO it would be better to split this patch into the refactor portion, > which will explicitly keep ppc64 with the old default and then open the > debate about changing the default as another patch. Yeah, that makes a lot of sense. > For the change itself, I understand why it would be beneficial but AFAIK > we never did this before. Well, we've made changes that have effectively modified architecture-specific defaults in the past, but checking back it was mostly to fix scenarios where things wouldn't work at all, and we also keyed those off capabilities. So you're right, this is unusual and something that we might ultimately decide not to do. I'd be okay with that. Though it's a shame to have bad defaults in libvirt, what matters is that higher-level tools are doing the right thing, and they already are. > At the very least the PPC maintainers should > voice their opinion. We have a PPC maintainer in libvirt? :) -- Andrea Bolognani / Red Hat / Virtualization _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
