On Fri, Jun 24, 2016 at 23:50:43 +0200, Pavel Hrdina wrote: > On Fri, Jun 24, 2016 at 07:36:01PM +0200, Jiri Denemark wrote: > > Pretending (partial) support for something we don't understand is risky. > > Reporting a failure is much better. > > I agree that pretending support is risky, but I'm not sure about this. For > example it seems that someone uses libvirt on VIR_ARCH_OR32 (commit c88bf5726) > which should be probably included in cpu_arm driver. There are also some other > archs (VIR_ARCH_ALPHA, VIR_ARCH_PPCEMB, VIR_ARCH_SH4, VIR_ARCH_SH4EB, > VIR_ARCH_SPARC and VIR_ARCH_SPARC64 qemu_domain.c) that wouldn't be supported. > > I'm not an expert in this area, I'm just asking to make sure that we don't > break anything by removing the cpu_generic driver. One would think so, but in reality the generic driver was pretty useless anyway. The only CPU driver APIs it implemented were baseline and compare. Both of them expect that libvirt can report host CPU definition. It's not a strict requirement for baseline, since one can create the input XMLs even by hand, but compare has nothing to compare the supplied XML with if libvirt cannot detect a host CPU. And since the host CPU detection APIs were not implemented in generic driver, both baseline and compare could not really be used. For the more common case of just starting a domain of one of those architectures with a CPU model specified the following combinations are possible: - KVM (host is the same arch as guest) -- did not work due to the missing host CPU detection APIs - TCG when host arch == guest arch -- did not work for the same reason and because the qemu driver only allows a guest CPU to be selected when libvirt know what CPU model the host has (yes, this is wrong and I have a patch for it in my WIP series) - TCG when host arch is one of those supported by our CPU driver -- worked and will work because libvirt knows what CPU the host has (yes, this is even worse since the host CPU is completely irrelevant and I have a patch for this too) and the guest-arch's CPU driver is not used at all in this case (wrong too, patch in progress) In other words, the CPU driver and its interactions with QEMU driver is hopelessly broken and this patch does not make it any worse :-) Libvirt 2.1 should be much better in this respect I believe. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list