Message-ID: <CANRm+CwCXQkMTQ=jQ8t0EkKz_xQVP9Wkp+_ams319k=8avbBSw@mail.gmail.com>
Date:   Thu, 5 Oct 2017 18:57:03 +0800
From:   Wanpeng Li <kernellwp@...il.com>
To:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        kvm <kvm@...r.kernel.org>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Wanpeng Li <wanpeng.li@...mail.com>
Subject: Re: [PATCH v2 0/4] KVM: LAPIC: Rework lapic timer to behave more like real-hardware

2017-09-29 9:04 GMT+08:00 Wanpeng Li <kernellwp@...il.com>:
> The issue is reported in xen community.
>
> Anthony PERARD pointed out:
>
> https://www.mail-archive.com/xen-devel@lists.xen.org/msg117283.html#
>
>  | When developing PVH for OVMF, I've used the lapic timer. It turns out that the
>  | way it is used by OVMF did not work with Xen [1]. I tried to find out how
>  | real-hw behave, and write a XTF tests [2]. And this patch series tries to fix
>  | the behavior of the vlapic timer.
>  |
>  |
>  | The OVMF driver for the APIC timer initialize the timer like this:
>  |      write to TMICT (initial counter)
>  |      write to TMDCR (divide configuration)
>  |      enable the timer (this may change timer mode from one-shot to periodic)
>  | It turns out that TMICT is set to 0 on the last step, but OVMF expect the timer
>  | to run.
>  |
>  | Here is some description of the APIC timer, base on observation as well as read
>  | of the Intel SDM. The description is also patch of patch description
>  | (reworded).
>  |
>  | Maybe a way of thinking how the APIC timer is evaluated, is to think of how
>  | hardward will do it. There is a counter TMCCT which always keeps counting down.
>  |
>  | Setting TMICT also set TMCCT, nothing else matter.
>  | Setting LVTT does not change anything right away.
>  | Setting TMDCR does not change much.
>  |
>  | Now TMCCT keeps counting down, by a value related to TMDCR.
>  | Once, TMCCT reach 0, it is only at this time that LVTT is taken into account.
>  | Is there an interrupt to deliver? Should the timer restart counting from the
>  | value in TMICT?
>  |
>  | In the Intel SDM, there is the word "disarm" of the timer used. I guess the
>  | easier way to disarm the APIC timer (when in periodic or one-shot) is to set
>  | TMICT to 0. But if we take TSC-Deadline mode out of the picture, there is
>  | nothing in the manual that say that the timer is disarm or stopped when
>  | changing timer mode (there is only two modes left, period and one-shot).
>  |
>  | As for the TSC-deadline timer mode, observation shown that changing to it (or
>  | from it) does reset and disarm both timers, so effectively TMICT and the
>  | tscdeadline are set to 0.
>  |
>  | [1] https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg00959.html
>  | [2] v1:
>  | https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg02533.html
>  |     v2: look for "[XTF PATCH V2 0/3] Testing vlapic timer"
>
>  In addition, Patch 3/4 implements the illegal vector error handling according to
>  SDM 10.5.2~10.5.3.
>
> v1 -> v2:
>  * add cover-letter and collect recent lapic patches to one patchset
>
> Wanpeng Li (4):
>   KVM: LAPIC: Fix lapic timer mode transition
>   KVM: LAPIC: Keep timer running when switching between one-shot and periodic mode
>   KVM: LAPIC: Apply change to TDCR right away to the timer
>   KVM: LAPIC: Don't silently accept bad vectors

I just sent out a new version of patch 1~3 for v3, and patch 4 need
more time to verify.

Regards,
Wanpeng Li

>
>  arch/x86/include/asm/apicdef.h |  1 +
>  arch/x86/kvm/lapic.c           | 90 ++++++++++++++++++++++++++++++++++--------
>  2 files changed, 74 insertions(+), 17 deletions(-)
>
> --
> 2.7.4
>

Powered by blists - more mailing lists