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
