[Bug 1868692] Re: default cpu (qemu64) no more capable of nesting

2020-04-02 Thread Christian Ehrhardt 
** Changed in: ubuntu-release-notes Status: In Progress => Fix Released -- 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

[Bug 1868692] Re: default cpu (qemu64) no more capable of nesting

2020-04-02 Thread Christian Ehrhardt 
** Changed in: ubuntu-release-notes Status: New => In Progress -- 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

[Bug 1868692] Re: default cpu (qemu64) no more capable of nesting

2020-03-26 Thread Launchpad Bug Tracker
This bug was fixed in the package qemu - 1:4.2-3ubuntu4 --- qemu (1:4.2-3ubuntu4) focal; urgency=medium * d/p/ubuntu/lp-1835546-*: backport the s390x protvirt feature (LP: #1835546) * remove d/p/ubuntu/expose-vmx_qemu64cpu.patch: Stop adding VMX to qemu64 to avoid broken

[Bug 1868692] Re: default cpu (qemu64) no more capable of nesting

2020-03-26 Thread Christian Ehrhardt 
Tests are good still/again - the one failure is known and completely unrelated to Focal prep (x86_64): Pass 20 F/S/N 0/0/0 - RC 0 (15 min 55036 lin) migrate (x86_64) : Pass 288 F/S/N 0/0/0 - RC 0 (60 min 214809 lin) cross (x86_64) : Pass 24 F/S/N 0/1/3 - RC 0 (51 min 47738 lin)

[Bug 1868692] Re: default cpu (qemu64) no more capable of nesting

2020-03-26 Thread Christian Ehrhardt 
I was recently seeing a bug report that had a very similar signature but used host-passthrough. I was concerned enough on that failure to double check if that happens on the new builds as well. host-model gave me Haswell-noTSX-IBRS Intel ... long list of extra features ... => no

[Bug 1868692] Re: default cpu (qemu64) no more capable of nesting

2020-03-26 Thread Christian Ehrhardt 
All other tools but uvtool have modern default already. - virt-manager and such use a host-model like named cpu-type by default - openstack uses named types as well - multipass uses host-passthrough (no migration in mind) The only thing open would be uvtool and to eventually resolve that I filed

[Bug 1868692] Re: default cpu (qemu64) no more capable of nesting

2020-03-26 Thread Christian Ehrhardt 
qemu64 also appears as AMD/SVM cpu - I think it really is time to stop our qemu64 type to be special, mention that (and better alternatives) in the release notes and close this issue. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1868692] Re: default cpu (qemu64) no more capable of nesting

2020-03-26 Thread Christian Ehrhardt 
Q: Have I seen this crash appear and vanish by accident and is it still there with VMX flag not set? This uses the code that no more adds the VMX flag (and due to that doesn't enable it by default) - qemu64 - nested can't be used - qemu64,vmx=on - nested can be used => Still Crashes! -

[Bug 1868692] Re: default cpu (qemu64) no more capable of nesting

2020-03-26 Thread Christian Ehrhardt 
TODO: I want to do some further tests on this with the intended uploads -- 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

[Bug 1868692] Re: default cpu (qemu64) no more capable of nesting

2020-03-26 Thread Christian Ehrhardt 
The libvirt type doesn't add vmx=on (as expected since it defines the existing features). Test: - no type - qemu64 type withotu vmx=on, no nesting as-is - qemu64 type - qemu64 type withotu vmx=on, no nesting as-is - qemu64 with vmx - nested working - kvm64 type - kvm64 type withotu vmx=on, no

[Bug 1868692] Re: default cpu (qemu64) no more capable of nesting

2020-03-26 Thread Christian Ehrhardt 
I wanted another round of tests and it seems that was good. With the subset of VMX features it fails to start the nested guest. KVM: entry failed, hardware error 0x8021 That is a known issue on older HW due to a lack of VMX features and bugs in the kernel around it. It came back and was

[Bug 1868692] Re: default cpu (qemu64) no more capable of nesting

2020-03-24 Thread Christian Ehrhardt 
With the next build I got something even closer to the old behavior. No CPU tag gave me: qemu64 I'm able to disable it via which becomes -cpu qemu64,vmx=off With that change the former upgrade bug would be fixed. The one decision we have to make is

[Bug 1868692] Re: default cpu (qemu64) no more capable of nesting

2020-03-24 Thread Christian Ehrhardt 
With the current build: sudo qemu-system-x86_64 --enable-kvm --nographic --nodefaults -S -qmp-pretty stdio {"execute":"qmp_capabilities"} {"execute":"query-cpu-definitions"} { "name": "qemu64", "typename": "qemu64-x86_64-cpu", "unavailable-features": [

[Bug 1868692] Re: default cpu (qemu64) no more capable of nesting

2020-03-24 Thread Christian Ehrhardt 
With the fix applied, the most reduced case is: qemu64 Which ends up as: -cpu qemu64 That is without VMX (as expected) If adding FMX as feature (didn't work to enable it before) qemu64 => Nested KVM works => It got a smaller subset of cpuflags than

[Bug 1868692] Re: default cpu (qemu64) no more capable of nesting

2020-03-24 Thread Launchpad Bug Tracker
** Merge proposal linked: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/381033 -- 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