# Similar to my test in comment #7, but with slighly modified XML as in [1]
Start on Xenial, upgrade one by one

At the spot of xx CPU xx I had one of the following:

hm - host model
  <cpu mode='host-model'>
    <model fallback='allow'/>
  </cpu>
hp - host passthrough
  <cpu mode='host-passthrough'>
     <model fallback='allow'/>
  </cpu>
maf - match allow fallback
  <cpu mode='custom' match='exact'>
     <model fallback='allow'>host</model>
  </cpu>
mff - match forbid fallback
  <cpu mode='custom' match='exact'>
     <model fallback='forbid'>host</model>
  </cpu>

Those four modes to some extend mean the same "make it as close to the host cpu as possible" with slight differences, see [2]. And the "bonus" that host-model was broken until soon to be released qemu/libvirt versions.

Adding next release in sources and using "apt-get install -t" I was able to test qemu/libvirt upgrades one by one.

Testing:                  hm       hp       maf     mff
LV 1.3.1 / Qemu 2.5       ok       ok        ok      ok
LV 1.3.1 / Qemu 2.6.1     fails by LV 1.3.1 not able to handle virt-2.6
LV 2.1   / Qemu 2.6.1     ok       ok        ok      ok
LV 2.1   / Qemu 2.8       ok       ok        ok      ok
LV 2.5   / Qemu 2.8       fail     ok        ok      ok

All of the rest of the system is still as on Xenial, so we can exclude other packages.

We can see that "only" host-model regressed, certainly due to the mentioned changes that it was broken so far.

By that we get to the libvirt code that corey already posted.
That code changed a lot 2.1-2.5.
To some extend it comes down to the check in virQEMUCapsIsCPUModeSupported, but I need to find the changes that lead to add the "host-model doesn't work" statement in the xml doc to get more background.

The whole call to qemuProcessUpdateGuestCPU did not exist in 2.1, to some extend the old check was "qemuProcessStartValidateGuestCPU".
The introduction of the check that now breaks was in 803497a8 that added virQEMUCapsIsCPUModeSupported which checks against "!!qemuCaps->hostCPUModel".
That in turn 
Related changes:
- http://libvirt.org/git/?p=libvirt.git;a=commit;h=7ce711a30eaf882ccd0217b2528362b563b6d670 (2.3)
- http://libvirt.org/git/?p=libvirt.git;a=commit;h=803497a8acdc76b9b229bd27d595ec89beed2f3e (2.3)

I checked that on x86 host-model works with libvirt 2.5.
That means there the qemuCaps hold this flag.

After confirming that known it was "easy" to have a much simpler check.
The capabilities this is checked is like "the guest wants X can the emulator run X".
Not that is as easy as:
$ virsh domcapabilities --emulatorbin /usr/bin/qemu-system-aarch64 | grep host-model
    <mode name='host-model' supported='no'/>
While
$ virsh domcapabilities --emulatorbin /usr/bin/qemu-system-x86_64 | grep host-model
    <mode name='host-model' supported='yes'>

With that I went back to
libvirt 2.1 on arm and there the whole cpu section was not populated (and as outlined libvirt did not check against it even if it would be).

I want to check how this is populated and also the commits that lead to the doc in the xml stating that host-model was flawed before L3.2/Q2.9.

But before knowing better I'd say libvirt is right to reject it if the emulator bin is not supporting it. I'll update when I have more in a bit.

[1]: http://paste.ubuntu.com/24233826/
[2]: https://libvirt.org/formatdomain.html#elementsCPU