2017-02-08 11:50 GMT+03:00 Paolo Bonzini <pbonzini@xxxxxxxxxx>:
>
>
> 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@xxxxxxxxx
