[BISECTED REGRESSION] v4.0+ KVM: x86: allow TSC deadline timer on all hosts

[BISECTED REGRESSION] v4.0+ KVM: x86: allow TSC deadline timer on all hosts

[Matwey V. Kornilov]

Hello,

I've bisected that commit defcf51fa93929bd ("KVM: x86: allow TSC
deadline timer on all hosts") makes guest kernels crash under specific
circumstances.
The issue itself is the following. I use host linux kernel (was
bisected) to run guest linux kernels using qemu-kvm (version 2.3.1.
earlier version 2.1 has also been checked and found demonstrating the
same behavior)

I've found that

1) the following qemu command

qemu-system-x86_64 -machine accel=kvm -nodefaults -no-reboot
-nographic -cpu host -vga none  -kernel kernel  -initrd initrd -append
'panic=1 no-kvmclock console=ttyS0 loglevel=7' -m 1024 -serial stdio

successfully boots the guest kernel when host kernel version is prior
defcf51fa93929bd (3.16 3.18 3.19 was checked)

2) the same command leads to the guest kernel failure with the same
qemu binary and the same kernel and initrd images when host kernel
4.0+ is used (4.0 4.4 4.9 was checked):

[    0.588000] divide error: 0000 [#1] SMP
[    0.588000] Modules linked in:
[    0.588000] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W
3.16.6-2-default #1
[    0.588000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.8.1-0-g4adadbd-20150316_085822-nilsson.home.kraxel.org
04/01/2014
[    0.588000] task: ffff88003d61e010 ti: ffff88003d63c000 task.ti:
ffff88003d63c000
[    0.588000] RIP: 0010:[<ffffffff810c6e7f>]  [<ffffffff810c6e7f>]
clockevents_config.part.3+0x1f/0xa0
[    0.588000] RSP: 0000:ffff88003d63fe90  EFLAGS: 00010246
[    0.588000] RAX: ffffffffffffffff RBX: ffff88003f80ce80 RCX: 0000000000000000
[    0.588000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffffffffff
[    0.588000] RBP: 000000000000b060 R08: 0000000000000001 R09: ffffffff81ee84b0
[    0.588000] R10: 00000000000000bb R11: 0000000000000003 R12: 000000000000b0a0
[    0.588000] R13: 0000000000000200 R14: 0000000000000000 R15: 0000000000000000
[    0.588000] FS:  0000000000000000(0000) GS:ffff88003f800000(0000)
knlGS:0000000000000000
[    0.588000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[    0.588000] CR2: 00000000ffffffff CR3: 0000000001c13000 CR4: 00000000000006f0
[    0.588000] Stack:
[    0.588000]  ffff88003f80ce80 000000000000b060 000000000000b0a0
ffffffff810c73cc
[    0.588000]  0000000000000000 ffffffff81d15952 ffffffff81e63338
0000000000000000
[    0.588000]  0000000000000000 0000000000000000 ffffffff81d0910c
0000000000000000
[    0.588000] Call Trace:
[    0.588000]  [<ffffffff810c73cc>] clockevents_config_and_register+0x1c/0x30
[    0.588000]  [<ffffffff81d15952>] native_smp_prepare_cpus+0x3a1/0x3d0
[    0.588000]  [<ffffffff81d0910c>] kernel_init_freeable+0xc1/0x202
[    0.588000]  [<ffffffff815bc04a>] kernel_init+0xa/0xf0
[    0.588000]  [<ffffffff815d0b7c>] ret_from_fork+0x7c/0xb0
[    0.588000] Code: 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66
90 41 54 31 d2 89 f1 89 f6 41 b8 01 00 00 00 55 53 48 89 fb 48 8b 7f
70 48 89 f8 <48> f7 f6 48 85 c0 74 0b 48 3d 58 02 00 00 41 89 c0 77 4e
4c 8d
[    0.588000] RIP  [<ffffffff810c6e7f>] clockevents_config.part.3+0x1f/0xa0
[    0.588000]  RSP <ffff88003d63fe90>
[    0.592000] ---[ end trace 6dcb37223984f47d ]---
[    0.596000] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b

As soon as the guest kernel were bootable before in this
configuration, I think this could be a regression. But I am not sure
how the commit exactly affects the behavior.

I've also tried to understand what was happening inside the guest
kernel native_calibrate_tsc() function. Nothing interesting except
that both tsc1 and tsc2 are ULLONG_MAX after the for loop.

References: https://bugzilla.opensuse.org/show_bug.cgi?id=1023358

-- 
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2207@jabber.ru

Re: [BISECTED REGRESSION] v4.0+ KVM: x86: allow TSC deadline timer on all hosts

[Wanpeng Li]

2017-02-05 16:39 GMT+08:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:
> Hello,
>
> I've bisected that commit defcf51fa93929bd ("KVM: x86: allow TSC
> deadline timer on all hosts") makes guest kernels crash under specific
> circumstances.
> The issue itself is the following. I use host linux kernel (was
> bisected) to run guest linux kernels using qemu-kvm (version 2.3.1.
> earlier version 2.1 has also been checked and found demonstrating the
> same behavior)
>
> I've found that
>
> 1) the following qemu command
>
> qemu-system-x86_64 -machine accel=kvm -nodefaults -no-reboot
> -nographic -cpu host -vga none  -kernel kernel  -initrd initrd -append
> 'panic=1 no-kvmclock console=ttyS0 loglevel=7' -m 1024 -serial stdio
>
> successfully boots the guest kernel when host kernel version is prior
> defcf51fa93929bd (3.16 3.18 3.19 was checked)
>
> 2) the same command leads to the guest kernel failure with the same
> qemu binary and the same kernel and initrd images when host kernel
> 4.0+ is used (4.0 4.4 4.9 was checked):
>
> [    0.588000] divide error: 0000 [#1] SMP
> [    0.588000] Modules linked in:
> [    0.588000] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W
> 3.16.6-2-default #1
> [    0.588000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS rel-1.8.1-0-g4adadbd-20150316_085822-nilsson.home.kraxel.org
> 04/01/2014
> [    0.588000] task: ffff88003d61e010 ti: ffff88003d63c000 task.ti:
> ffff88003d63c000
> [    0.588000] RIP: 0010:[<ffffffff810c6e7f>]  [<ffffffff810c6e7f>]
> clockevents_config.part.3+0x1f/0xa0
> [    0.588000] RSP: 0000:ffff88003d63fe90  EFLAGS: 00010246
> [    0.588000] RAX: ffffffffffffffff RBX: ffff88003f80ce80 RCX: 0000000000000000
> [    0.588000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffffffffff
> [    0.588000] RBP: 000000000000b060 R08: 0000000000000001 R09: ffffffff81ee84b0
> [    0.588000] R10: 00000000000000bb R11: 0000000000000003 R12: 000000000000b0a0
> [    0.588000] R13: 0000000000000200 R14: 0000000000000000 R15: 0000000000000000
> [    0.588000] FS:  0000000000000000(0000) GS:ffff88003f800000(0000)
> knlGS:0000000000000000
> [    0.588000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [    0.588000] CR2: 00000000ffffffff CR3: 0000000001c13000 CR4: 00000000000006f0
> [    0.588000] Stack:
> [    0.588000]  ffff88003f80ce80 000000000000b060 000000000000b0a0
> ffffffff810c73cc
> [    0.588000]  0000000000000000 ffffffff81d15952 ffffffff81e63338
> 0000000000000000
> [    0.588000]  0000000000000000 0000000000000000 ffffffff81d0910c
> 0000000000000000
> [    0.588000] Call Trace:
> [    0.588000]  [<ffffffff810c73cc>] clockevents_config_and_register+0x1c/0x30
> [    0.588000]  [<ffffffff81d15952>] native_smp_prepare_cpus+0x3a1/0x3d0
> [    0.588000]  [<ffffffff81d0910c>] kernel_init_freeable+0xc1/0x202
> [    0.588000]  [<ffffffff815bc04a>] kernel_init+0xa/0xf0
> [    0.588000]  [<ffffffff815d0b7c>] ret_from_fork+0x7c/0xb0
> [    0.588000] Code: 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66
> 90 41 54 31 d2 89 f1 89 f6 41 b8 01 00 00 00 55 53 48 89 fb 48 8b 7f
> 70 48 89 f8 <48> f7 f6 48 85 c0 74 0b 48 3d 58 02 00 00 41 89 c0 77 4e
> 4c 8d
> [    0.588000] RIP  [<ffffffff810c6e7f>] clockevents_config.part.3+0x1f/0xa0
> [    0.588000]  RSP <ffff88003d63fe90>
> [    0.592000] ---[ end trace 6dcb37223984f47d ]---
> [    0.596000] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0000000b
>
> As soon as the guest kernel were bootable before in this
> configuration, I think this could be a regression. But I am not sure
> how the commit exactly affects the behavior.
>
> I've also tried to understand what was happening inside the guest
> kernel native_calibrate_tsc() function. Nothing interesting except
> that both tsc1 and tsc2 are ULLONG_MAX after the for loop.
>
> References: https://bugzilla.opensuse.org/show_bug.cgi?id=1023358

It is the guest kernel bug, please refers to commit b47dcbdc516 (x86,
apic: Handle a bad TSC more gracefully).

Regards,
Wanpeng Li

Re: [BISECTED REGRESSION] v4.0+ KVM: x86: allow TSC deadline timer on all hosts

[Matwey V. Kornilov]

2017-02-05 16:21 GMT+03:00 Wanpeng Li <kernellwp@gmail.com>:
> 2017-02-05 16:39 GMT+08:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:
>> Hello,
>>
>> I've bisected that commit defcf51fa93929bd ("KVM: x86: allow TSC
>> deadline timer on all hosts") makes guest kernels crash under specific
>> circumstances.
>> The issue itself is the following. I use host linux kernel (was
>> bisected) to run guest linux kernels using qemu-kvm (version 2.3.1.
>> earlier version 2.1 has also been checked and found demonstrating the
>> same behavior)
>>
>> I've found that
>>
>> 1) the following qemu command
>>
>> qemu-system-x86_64 -machine accel=kvm -nodefaults -no-reboot
>> -nographic -cpu host -vga none  -kernel kernel  -initrd initrd -append
>> 'panic=1 no-kvmclock console=ttyS0 loglevel=7' -m 1024 -serial stdio
>>
>> successfully boots the guest kernel when host kernel version is prior
>> defcf51fa93929bd (3.16 3.18 3.19 was checked)
>>
>> 2) the same command leads to the guest kernel failure with the same
>> qemu binary and the same kernel and initrd images when host kernel
>> 4.0+ is used (4.0 4.4 4.9 was checked):
>>
>> [    0.588000] divide error: 0000 [#1] SMP
>> [    0.588000] Modules linked in:
>> [    0.588000] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W
>> 3.16.6-2-default #1
>> [    0.588000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>> BIOS rel-1.8.1-0-g4adadbd-20150316_085822-nilsson.home.kraxel.org
>> 04/01/2014
>> [    0.588000] task: ffff88003d61e010 ti: ffff88003d63c000 task.ti:
>> ffff88003d63c000
>> [    0.588000] RIP: 0010:[<ffffffff810c6e7f>]  [<ffffffff810c6e7f>]
>> clockevents_config.part.3+0x1f/0xa0
>> [    0.588000] RSP: 0000:ffff88003d63fe90  EFLAGS: 00010246
>> [    0.588000] RAX: ffffffffffffffff RBX: ffff88003f80ce80 RCX: 0000000000000000
>> [    0.588000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffffffffff
>> [    0.588000] RBP: 000000000000b060 R08: 0000000000000001 R09: ffffffff81ee84b0
>> [    0.588000] R10: 00000000000000bb R11: 0000000000000003 R12: 000000000000b0a0
>> [    0.588000] R13: 0000000000000200 R14: 0000000000000000 R15: 0000000000000000
>> [    0.588000] FS:  0000000000000000(0000) GS:ffff88003f800000(0000)
>> knlGS:0000000000000000
>> [    0.588000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [    0.588000] CR2: 00000000ffffffff CR3: 0000000001c13000 CR4: 00000000000006f0
>> [    0.588000] Stack:
>> [    0.588000]  ffff88003f80ce80 000000000000b060 000000000000b0a0
>> ffffffff810c73cc
>> [    0.588000]  0000000000000000 ffffffff81d15952 ffffffff81e63338
>> 0000000000000000
>> [    0.588000]  0000000000000000 0000000000000000 ffffffff81d0910c
>> 0000000000000000
>> [    0.588000] Call Trace:
>> [    0.588000]  [<ffffffff810c73cc>] clockevents_config_and_register+0x1c/0x30
>> [    0.588000]  [<ffffffff81d15952>] native_smp_prepare_cpus+0x3a1/0x3d0
>> [    0.588000]  [<ffffffff81d0910c>] kernel_init_freeable+0xc1/0x202
>> [    0.588000]  [<ffffffff815bc04a>] kernel_init+0xa/0xf0
>> [    0.588000]  [<ffffffff815d0b7c>] ret_from_fork+0x7c/0xb0
>> [    0.588000] Code: 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66
>> 90 41 54 31 d2 89 f1 89 f6 41 b8 01 00 00 00 55 53 48 89 fb 48 8b 7f
>> 70 48 89 f8 <48> f7 f6 48 85 c0 74 0b 48 3d 58 02 00 00 41 89 c0 77 4e
>> 4c 8d
>> [    0.588000] RIP  [<ffffffff810c6e7f>] clockevents_config.part.3+0x1f/0xa0
>> [    0.588000]  RSP <ffff88003d63fe90>
>> [    0.592000] ---[ end trace 6dcb37223984f47d ]---
>> [    0.596000] Kernel panic - not syncing: Attempted to kill init!
>> exitcode=0x0000000b
>>
>> As soon as the guest kernel were bootable before in this
>> configuration, I think this could be a regression. But I am not sure
>> how the commit exactly affects the behavior.
>>
>> I've also tried to understand what was happening inside the guest
>> kernel native_calibrate_tsc() function. Nothing interesting except
>> that both tsc1 and tsc2 are ULLONG_MAX after the for loop.
>>
>> References: https://bugzilla.opensuse.org/show_bug.cgi?id=1023358
>
> It is the guest kernel bug, please refers to commit b47dcbdc516 (x86,
> apic: Handle a bad TSC more gracefully).
>

Hello,

Frankly speaking it is always unclear to me where the criterion is. If
it is a bug in guest kernel, why did it ever work with elder host
kernel?

-- 
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2207@jabber.ru

Re: [BISECTED REGRESSION] v4.0+ KVM: x86: allow TSC deadline timer on all hosts

[Matwey V. Kornilov]

As far as I understand

kvm_ioctl(s, KVM_CHECK_EXTENSION, KVM_CAP_TSC_DEADLINE_TIMER)

returned 0 to user-space in my configuration before the commit
defcf51fa93929bd ("KVM: x86: allow TSC
> deadline timer on all hosts")

and it returns 1 after the commit. This is why qemu-kvm shows the
guest that tsc_deadline is present in CPU whereas it is not. See
target-i386/kvm.c for reference.
I am not sure that user-space behavior should change. Also I am not
sure that qemu should show unsupported CPU flags to guests.


2017-02-05 11:39 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:
> Hello,
>
> I've bisected that commit defcf51fa93929bd ("KVM: x86: allow TSC
> deadline timer on all hosts") makes guest kernels crash under specific
> circumstances.
> The issue itself is the following. I use host linux kernel (was
> bisected) to run guest linux kernels using qemu-kvm (version 2.3.1.
> earlier version 2.1 has also been checked and found demonstrating the
> same behavior)
>
> I've found that
>
> 1) the following qemu command
>
> qemu-system-x86_64 -machine accel=kvm -nodefaults -no-reboot
> -nographic -cpu host -vga none  -kernel kernel  -initrd initrd -append
> 'panic=1 no-kvmclock console=ttyS0 loglevel=7' -m 1024 -serial stdio
>
> successfully boots the guest kernel when host kernel version is prior
> defcf51fa93929bd (3.16 3.18 3.19 was checked)
>
> 2) the same command leads to the guest kernel failure with the same
> qemu binary and the same kernel and initrd images when host kernel
> 4.0+ is used (4.0 4.4 4.9 was checked):
>
> [    0.588000] divide error: 0000 [#1] SMP
> [    0.588000] Modules linked in:
> [    0.588000] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W
> 3.16.6-2-default #1
> [    0.588000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS rel-1.8.1-0-g4adadbd-20150316_085822-nilsson.home.kraxel.org
> 04/01/2014
> [    0.588000] task: ffff88003d61e010 ti: ffff88003d63c000 task.ti:
> ffff88003d63c000
> [    0.588000] RIP: 0010:[<ffffffff810c6e7f>]  [<ffffffff810c6e7f>]
> clockevents_config.part.3+0x1f/0xa0
> [    0.588000] RSP: 0000:ffff88003d63fe90  EFLAGS: 00010246
> [    0.588000] RAX: ffffffffffffffff RBX: ffff88003f80ce80 RCX: 0000000000000000
> [    0.588000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffffffffff
> [    0.588000] RBP: 000000000000b060 R08: 0000000000000001 R09: ffffffff81ee84b0
> [    0.588000] R10: 00000000000000bb R11: 0000000000000003 R12: 000000000000b0a0
> [    0.588000] R13: 0000000000000200 R14: 0000000000000000 R15: 0000000000000000
> [    0.588000] FS:  0000000000000000(0000) GS:ffff88003f800000(0000)
> knlGS:0000000000000000
> [    0.588000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [    0.588000] CR2: 00000000ffffffff CR3: 0000000001c13000 CR4: 00000000000006f0
> [    0.588000] Stack:
> [    0.588000]  ffff88003f80ce80 000000000000b060 000000000000b0a0
> ffffffff810c73cc
> [    0.588000]  0000000000000000 ffffffff81d15952 ffffffff81e63338
> 0000000000000000
> [    0.588000]  0000000000000000 0000000000000000 ffffffff81d0910c
> 0000000000000000
> [    0.588000] Call Trace:
> [    0.588000]  [<ffffffff810c73cc>] clockevents_config_and_register+0x1c/0x30
> [    0.588000]  [<ffffffff81d15952>] native_smp_prepare_cpus+0x3a1/0x3d0
> [    0.588000]  [<ffffffff81d0910c>] kernel_init_freeable+0xc1/0x202
> [    0.588000]  [<ffffffff815bc04a>] kernel_init+0xa/0xf0
> [    0.588000]  [<ffffffff815d0b7c>] ret_from_fork+0x7c/0xb0
> [    0.588000] Code: 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66
> 90 41 54 31 d2 89 f1 89 f6 41 b8 01 00 00 00 55 53 48 89 fb 48 8b 7f
> 70 48 89 f8 <48> f7 f6 48 85 c0 74 0b 48 3d 58 02 00 00 41 89 c0 77 4e
> 4c 8d
> [    0.588000] RIP  [<ffffffff810c6e7f>] clockevents_config.part.3+0x1f/0xa0
> [    0.588000]  RSP <ffff88003d63fe90>
> [    0.592000] ---[ end trace 6dcb37223984f47d ]---
> [    0.596000] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0000000b
>
> As soon as the guest kernel were bootable before in this
> configuration, I think this could be a regression. But I am not sure
> how the commit exactly affects the behavior.
>
> I've also tried to understand what was happening inside the guest
> kernel native_calibrate_tsc() function. Nothing interesting except
> that both tsc1 and tsc2 are ULLONG_MAX after the for loop.
>
> References: https://bugzilla.opensuse.org/show_bug.cgi?id=1023358
>
> --
> With best regards,
> Matwey V. Kornilov
> http://blog.matwey.name
> xmpp://0x2207@jabber.ru



-- 
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2207@jabber.ru

Re: [BISECTED REGRESSION] v4.0+ KVM: x86: allow TSC deadline timer on all hosts

[Paolo Bonzini]

On 07/02/2017 21:43, Matwey V. Kornilov wrote:
> As far as I understand
> 
> kvm_ioctl(s, KVM_CHECK_EXTENSION, KVM_CAP_TSC_DEADLINE_TIMER)
> 
> returned 0 to user-space in my configuration before the commit
> defcf51fa93929bd ("KVM: x86: allow TSC
>> deadline timer on all hosts")
> and it returns 1 after the commit. This is why qemu-kvm shows the
> guest that tsc_deadline is present in CPU whereas it is not. See
> target-i386/kvm.c for reference.

Yes, and that's because TSC deadline emulation does not use the host's
TSC deadline timer.  Therefore, even if the host doesn't have a TSC
deadline timer it is valid to expose the feature to the guest.

The bug was that Linux tried to use the TSC deadline timer even if it
disabled the TSC altogether.  The symptom were a division by zero
because the TSC frequency variable was not initialized.  This is quite
clearly a guest kernel bug.

> I am not sure that user-space behavior should change. Also I am not
> sure that qemu should show unsupported CPU flags to guests.

Userspace behavior changed only because you used "-cpu host".  "-cpu
host" tells QEMU to enable everything the kernel can enable, so it can
break when you update the host kernel.

Without "-cpu host" (e.g. "-cpu Nehalem"), either there would have been
no change in behavior, or you'd have had a warning before

warning: host doesn't support requested feature:
CPUID.1H:ECX.tsc_deadline_timer [bit 24]

and no warning afterwards.  Is this with KVM nested under VMware, as in
your launchpad bug report?

Paolo

Re: [BISECTED REGRESSION] v4.0+ KVM: x86: allow TSC deadline timer on all hosts

[Matwey V. Kornilov]

2017-02-08 11:50 GMT+03:00 Paolo Bonzini <pbonzini@redhat.com>:
>
>
> On 07/02/2017 21:43, Matwey V. Kornilov wrote:
>> As far as I understand
>>
>> kvm_ioctl(s, KVM_CHECK_EXTENSION, KVM_CAP_TSC_DEADLINE_TIMER)
>>
>> returned 0 to user-space in my configuration before the commit
>> defcf51fa93929bd ("KVM: x86: allow TSC
>>> deadline timer on all hosts")
>> and it returns 1 after the commit. This is why qemu-kvm shows the
>> guest that tsc_deadline is present in CPU whereas it is not. See
>> target-i386/kvm.c for reference.
>
> Yes, and that's because TSC deadline emulation does not use the host's
> TSC deadline timer.  Therefore, even if the host doesn't have a TSC
> deadline timer it is valid to expose the feature to the guest.
>
> The bug was that Linux tried to use the TSC deadline timer even if it
> disabled the TSC altogether.  The symptom were a division by zero
> because the TSC frequency variable was not initialized.  This is quite
> clearly a guest kernel bug.
>

Thanks, now it is becoming clear.

>> I am not sure that user-space behavior should change. Also I am not
>> sure that qemu should show unsupported CPU flags to guests.
>
> Userspace behavior changed only because you used "-cpu host".  "-cpu
> host" tells QEMU to enable everything the kernel can enable, so it can
> break when you update the host kernel.
>
> Without "-cpu host" (e.g. "-cpu Nehalem"), either there would have been
> no change in behavior, or you'd have had a warning before
>
> warning: host doesn't support requested feature:
> CPUID.1H:ECX.tsc_deadline_timer [bit 24]

-cpu host,-tsc-deadline also works.

> and no warning afterwards.  Is this with KVM nested under VMware, as in
> your launchpad bug report?

Yes. It is nested under VMware.

>
> Paolo



-- 
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2207@jabber.ru

Re: [BISECTED REGRESSION] v4.0+ KVM: x86: allow TSC deadline timer on all hosts

[Paolo Bonzini]

On 08/02/2017 17:26, Matwey V. Kornilov wrote:
> 2017-02-08 11:50 GMT+03:00 Paolo Bonzini <pbonzini@redhat.com>:
>> On 07/02/2017 21:43, Matwey V. Kornilov wrote:
>>> I am not sure that user-space behavior should change. Also I am not
>>> sure that qemu should show unsupported CPU flags to guests.
>>
>> Userspace behavior changed only because you used "-cpu host".  "-cpu
>> host" tells QEMU to enable everything the kernel can enable, so it can
>> break when you update the host kernel.
>>
>> Without "-cpu host" (e.g. "-cpu Nehalem"), either there would have been
>> no change in behavior, or you'd have had a warning before
>>
>> warning: host doesn't support requested feature:
>> CPUID.1H:ECX.tsc_deadline_timer [bit 24]
> 
> -cpu host,-tsc-deadline also works.
> 
>> and no warning afterwards.  Is this with KVM nested under VMware, as in
>> your launchpad bug report?
> 
> Yes. It is nested under VMware.

So the root cause here is that Linux doesn't like VMware's TSC.

Paolo