Further I realized that I can trigger this with T3.13/Q2.5/B4.15:
trusty-lvl1-mitaka kernel: [ 931.946357] kvm [2356]: vcpu0 unhandled rdmsr:
0x140
trusty-lvl1-mitaka kernel: [ 932.236914] kvm [2356]: vcpu0 unhandled rdmsr:
0x1c9
trusty-lvl1-mitaka kernel: [ 932.238337] kvm [2356]: vcpu0 unhandled rdmsr:
0x1a6
trusty-lvl1-mitaka kernel: [ 932.239622] kvm [2356]: vcpu0 unhandled rdmsr:
0x1a7
trusty-lvl1-mitaka kernel: [ 932.240956] kvm [2356]: vcpu0 unhandled rdmsr:
0x3f6
trusty-lvl1-mitaka kernel: [ 932.242179] kvm [2356]: vcpu0 unhandled rdmsr:
0x3f7
trusty-lvl1-mitaka kernel: [ 935.038854] kvm [2356]: vcpu0 unhandled rdmsr:
0x64e
trusty-lvl1-mitaka kernel: [ 935.040086] kvm [2356]: vcpu0 unhandled rdmsr:
0x34
Which in the guest is a crash
[ 0.000000] XSAVE consistency problem, dumping leaves
[ 0.000000] WARNING: CPU: 0 PID: 0 at
/build/linux-3btXxq/linux-4.15.0/arch/x86/kernel/fpu/xstate.c:614
do_extra_xstate_size_checks+0x303/0x3e6
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.15.0-50-generic
#54-Ubuntu
[ 0.000000] RIP: 0010:do_extra_xstate_size_checks+0x303/0x3e6
[ 0.000000] RSP: 0000:ffffffffa6003d50 EFLAGS: 00010086 ORIG_RAX:
0000000000000000
[ 0.000000] RAX: 0000000000000000 RBX: 000000000000000a RCX: ffffffffa60627a8
[ 0.000000] RDX: 0000000000000001 RSI: 0000000000000086 RDI: 0000000000000047
[ 0.000000] RBP: ffffffffa6003d90 R08: 657661656c20676e R09: 0000000000000007
[ 0.000000] R10: ffffffffa625a600 R11: 0000000000000000 R12: 0000000000000100
[ 0.000000] R13: 0000000000000340 R14: ffffffffa6003d54 R15: ffffffffa6003d50
[ 0.000000] FS: 0000000000000000(0000) GS:ffffffffa627f000(0000)
knlGS:0000000000000000
[ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.000000] CR2: ffff88800008a000 CR3: 0000000013d22000 CR4: 00000000000406a0
[ 0.000000] Call Trace:
[ 0.000000] ? init_scattered_cpuid_features+0x86/0x110
[ 0.000000] fpu__init_system_xstate+0x183/0x484
[ 0.000000] fpu__init_system+0x213/0x265
[ 0.000000] ? early_init_intel+0x270/0x450
[ 0.000000] early_cpu_init+0x269/0x270
[ 0.000000] ? 0xffffffffa4c00000
[ 0.000000] setup_arch+0xcb/0xc82
[ 0.000000] ? printk+0x52/0x6e
[ 0.000000] start_kernel+0x6d/0x4fd
[ 0.000000] x86_64_start_reservations+0x24/0x26
[ 0.000000] x86_64_start_kernel+0x74/0x77
[ 0.000000] secondary_startup_64+0xa5/0xb0
I can avoid that particular error with a modification like:
<cpu mode='host-passthrough'>
<feature policy='disable' name='xsave'/>
</cpu>
But then another issue shows up ... (and so on)
I eventually got things running (for the tests) with
<cpu mode='host-model'>
<model fallback='forbid'/>
<feature policy='require' name='md-clear'/>
</cpu>
That might be an issue with xsave and other features in old nested, but this
further underlines my point on nested being nice but unreliable - at least "in
the past".
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1829555
Title:
nested virtualization w/first level trusty guests has odd MDS behavior
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829555/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
