[libvirt] [PATCH 2/3] cpu: Drop generic driver

[Jiri Denemark]

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