Comment 23 for bug 1829555

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".