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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1868692
Title:
default cpu (qemu64) no more capable of nesting
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1868692/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
