From: Anthony PERARD <anthony.perard@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Anthony PERARD <anthony.perard@citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Jan Beulich <jbeulich@suse.com>
Subject: [PATCH v3 0/3] Rework vlapic timer to behave more like real-hardware
Date: Tue, 8 Aug 2017 14:32:57 +0100 [thread overview]
Message-ID: <20170808133300.2277-1-anthony.perard@citrix.com> (raw)
Hi,
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.
There is a XTF patch series that check the emulation of the vlapic timer.
"[XTF PATCH V2 0/3] Testing vlapic timer"
This patch series can be found at:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
tag: vlapic-timer-v3
Changes in V3:
- details in patches.
Changes in V2:
- patches have been reworked.
- vlapic_update_timer does not care anymore which register is been changed.
- more comments, hopefully also better.
Thanks,
[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"
Anthony PERARD (3):
x86/vlapic: Introduce vlapic_update_timer
x86/vlapic: Keep timer running when switching between one-shot and
periodic mode
x86/vlapic: Apply change to TDCR right away to the timer
xen/arch/x86/hvm/vlapic.c | 126 ++++++++++++++++++++++++++++++++++------------
1 file changed, 94 insertions(+), 32 deletions(-)
--
Anthony PERARD
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next reply other threads:[~2017-08-08 13:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-08 13:32 Anthony PERARD [this message]
2017-08-08 13:32 ` [PATCH v3 1/3] x86/vlapic: Introduce vlapic_update_timer Anthony PERARD
2017-08-08 13:32 ` [PATCH v3 2/3] x86/vlapic: Keep timer running when switching between one-shot and periodic mode Anthony PERARD
2017-08-08 13:33 ` [PATCH v3 3/3] x86/vlapic: Apply change to TDCR right away to the timer Anthony PERARD
2017-08-25 14:40 ` [PATCH v3 0/3] Rework vlapic timer to behave more like real-hardware Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170808133300.2277-1-anthony.perard@citrix.com \
--to=anthony.perard@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).