On Mon, Aug 06, 2018 at 11:38:06AM +0200, Andrea Bolognani wrote: > On Fri, 2018-08-03 at 13:59 +0100, Daniel P. Berrangé wrote: > > It is increasingly likely that some distro is going to change the > > default "x86" machine type in QEMU from "pc" to "q35". This will > > certainly break existing applications which write their XML on the > > assumption that its using a "pc" machine by default. For example they'll > > s/its/it's/ > > > lack a IDE CDROM and get PCI-X instad of PCI which changes the topology > > s/PCI-X instad/PCIe instead/ > > [...] > > + /* Historically QEMU defaulted to 'pc' machine type but in > > + * future might switch 'q35'. Such a change is considered > > + * an ABI break from lbivirt's POV, so we must be sure to > > s/lbivirt/libvirt/ > > > + * keep 'pc' as default machine no matter what QEMU says. > > + */ > > + if (qemuCaps->arch == VIR_ARCH_X86_64 || > > + qemuCaps->arch == VIR_ARCH_I686) > > + preferredAlias = "pc"; > > You can use ARCH_IS_X86() here. > > Since we're shielding users from changes in the default x86 > machine type, I think it would make sense to do the same for other > architectures at the same time: for example, ppc64 should prefer > pseries, s390 should prefer s390-ccw-virtio and so on. > > I wonder how to handle architectures where QEMU never declared a > default machine type, such as aarch64 and riscv64, though: I think > it would make sense to prefer the virt machine type there, but I'm > not entirely sure that wouldn't cause any breakages either... Existing libvirt behaviour is that we'll pick the first reported machine type, so we have to preserve that. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
