Comment 3 for bug 1868692

With the next build I got something even closer to the old behavior.

No CPU tag gave me:
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>qemu64</model>
    <feature policy='require' name='vmx'/>
    <feature policy='require' name='x2apic'/>
    <feature policy='require' name='hypervisor'/>
    <feature policy='require' name='lahf_lm'/>
    <feature policy='disable' name='svm'/>
  </cpu>

I'm able to disable it via
   <feature policy='disable' name='vmx'/>
which becomes
   -cpu qemu64,vmx=off

With that change the former upgrade bug would be fixed.
The one decision we have to make is which features we announce on this cpu type.
In the past it was taking all features that it could and by that could have been different per host cpu. Now it takes a rather conservative small amount (but enough to do nesting).
The new default is more compatible and that is what the default type is for.
For a multitude of features it always was better to puck a defined (modern) named type.
Therefore it is the best choice to keep this small set. If people upgrade on new systems that is a slight loss in cpu guest features, but only speedup-bit of VMX. There is no set of features we could choose to avoid that, if we'd pick more older chips would trigger issues.

There seems to be no perfect answer, but the current patch at least fixes the identified bigger upgrade issue and is the most compatible one. The more recommended modern named types (also the default in any higher level management tool) provide a way to get consistent and feature rich guest CPUs.