* [BISECTED REGRESSION] v4.0+ KVM: x86: allow TSC deadline timer on all hosts
@ 2017-02-05 8:39 Matwey V. Kornilov
2017-02-05 13:21 ` Wanpeng Li
2017-02-07 20:43 ` Matwey V. Kornilov
0 siblings, 2 replies; 7+ messages in thread
From: Matwey V. Kornilov @ 2017-02-05 8:39 UTC (permalink / raw)
To: gleb, pbonzini, rkrcmar, kvm
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [BISECTED REGRESSION] v4.0+ KVM: x86: allow TSC deadline timer on all hosts
2017-02-05 8:39 [BISECTED REGRESSION] v4.0+ KVM: x86: allow TSC deadline timer on all hosts Matwey V. Kornilov
@ 2017-02-05 13:21 ` Wanpeng Li
2017-02-07 18:01 ` Matwey V. Kornilov
2017-02-07 20:43 ` Matwey V. Kornilov
1 sibling, 1 reply; 7+ messages in thread
From: Wanpeng Li @ 2017-02-05 13:21 UTC (permalink / raw)
To: Matwey V. Kornilov; +Cc: Gleb Natapov, Paolo Bonzini, Radim Krcmar, kvm
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [BISECTED REGRESSION] v4.0+ KVM: x86: allow TSC deadline timer on all hosts
2017-02-05 13:21 ` Wanpeng Li
@ 2017-02-07 18:01 ` Matwey V. Kornilov
0 siblings, 0 replies; 7+ messages in thread
From: Matwey V. Kornilov @ 2017-02-07 18:01 UTC (permalink / raw)
To: Wanpeng Li; +Cc: Gleb Natapov, Paolo Bonzini, Radim Krcmar, kvm
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [BISECTED REGRESSION] v4.0+ KVM: x86: allow TSC deadline timer on all hosts
2017-02-05 8:39 [BISECTED REGRESSION] v4.0+ KVM: x86: allow TSC deadline timer on all hosts Matwey V. Kornilov
2017-02-05 13:21 ` Wanpeng Li
@ 2017-02-07 20:43 ` Matwey V. Kornilov
2017-02-08 8:50 ` Paolo Bonzini
1 sibling, 1 reply; 7+ messages in thread
From: Matwey V. Kornilov @ 2017-02-07 20:43 UTC (permalink / raw)
To: Gleb Natapov, Paolo Bonzini, Radim Krcmar, kvm
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [BISECTED REGRESSION] v4.0+ KVM: x86: allow TSC deadline timer on all hosts
2017-02-07 20:43 ` Matwey V. Kornilov
@ 2017-02-08 8:50 ` Paolo Bonzini
2017-02-08 16:26 ` Matwey V. Kornilov
0 siblings, 1 reply; 7+ messages in thread
From: Paolo Bonzini @ 2017-02-08 8:50 UTC (permalink / raw)
To: Matwey V. Kornilov, Gleb Natapov, Radim Krcmar, kvm
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [BISECTED REGRESSION] v4.0+ KVM: x86: allow TSC deadline timer on all hosts
2017-02-08 8:50 ` Paolo Bonzini
@ 2017-02-08 16:26 ` Matwey V. Kornilov
2017-02-08 16:29 ` Paolo Bonzini
0 siblings, 1 reply; 7+ messages in thread
From: Matwey V. Kornilov @ 2017-02-08 16:26 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Gleb Natapov, Radim Krcmar, kvm
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [BISECTED REGRESSION] v4.0+ KVM: x86: allow TSC deadline timer on all hosts
2017-02-08 16:26 ` Matwey V. Kornilov
@ 2017-02-08 16:29 ` Paolo Bonzini
0 siblings, 0 replies; 7+ messages in thread
From: Paolo Bonzini @ 2017-02-08 16:29 UTC (permalink / raw)
To: Matwey V. Kornilov; +Cc: Gleb Natapov, Radim Krcmar, kvm
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-02-08 16:39 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-05 8:39 [BISECTED REGRESSION] v4.0+ KVM: x86: allow TSC deadline timer on all hosts Matwey V. Kornilov
2017-02-05 13:21 ` Wanpeng Li
2017-02-07 18:01 ` Matwey V. Kornilov
2017-02-07 20:43 ` Matwey V. Kornilov
2017-02-08 8:50 ` Paolo Bonzini
2017-02-08 16:26 ` Matwey V. Kornilov
2017-02-08 16:29 ` Paolo Bonzini
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.