From: Don Slutz <dslutz@verizon.com>
To: Jan Beulich <JBeulich@suse.com>, Don Slutz <dslutz@verizon.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [PATCH v2 06/10] hvm/hpet: comparator can only change when master clock is enabled.
Date: Tue, 15 Apr 2014 14:11:22 -0400 [thread overview]
Message-ID: <534D764A.7010606@terremark.com> (raw)
In-Reply-To: <534D771C02000078000091EE@nat28.tlf.novell.com>
On 04/15/14 12:14, Jan Beulich wrote:
>>>> On 15.04.14 at 17:53, <dslutz@verizon.com> wrote:
>> On 04/15/14 03:05, Jan Beulich wrote:
>>>>>> On 14.04.14 at 21:50, <dslutz@verizon.com> wrote:
>>>> On 04/14/14 11:07, Jan Beulich wrote:
>>>>> As to the change - I'm not sure: The quoted description from the
>>>>> specification cal also be read to mean that interrupt generation is
>>>>> optional, but comparator increment will always happen. As long as
>>>>> this can't be clarified, I'd prefer to stay with the code as is.
>>>> I think the code needs to change to match the spec.
>>>>
>>>> #define timer_enabled(h, n) (timer_config(h, n) & HPET_TN_ENABLE)
>>>>
>>>> vs
>>>>
>>>> #define hpet_enabled(h) (h->hpet.config & HPET_CFG_ENABLE)
>>>>
>>>>
>>>> The change uses hpet_enabled() (I.E. Overall Enable).
>>> Correct. But do we really need this? When the HPET is globally
>>> disabled, hpet_read_maincounter() returns a fixed value, and
>>> hence - due to the comparators not changing either -
>>> hpet_get_comparator() will too even without the addition. So if
>>> at all, the change would be mostly for documentation purposes.
>> We do need this. hpet_get_comparator() does not return a
>> fixed value. Without this change it will always adjust to
>> hpet_read_maincounter().
> But as said, hpet_read_maincounter() returns a fixed value in that
> case too (or at least it is supposed to be).
>
> And no, I'm not fully trusting the test program, so please explain
> things relative to the source code rather than by pointing at the
> test program showing something.
Ok,
Since this is all about when master clock is not enabled, I will
work with hpet_read_maincounter() returning a fix value. I will
also only talk about timer 0 (tn==0).
Since master clock, comparator, and period can all be set by
the guest, I am picking values:
master clock = 67752 (0x108a8)
comparator = 255252 (0x3e514)
period = 62500 (0xf424)
Using code as of:
commit d2b4c27c0718f27deba00a16317a8ba04c1a2cb7
xen/arm32: __cmpxchg_mb should be marked always_inline
86:static uint64_t hpet_get_comparator(HPETState *h, unsigned int tn)
87:{
88: uint64_t comparator;
89: uint64_t elapsed;
91: comparator = h->hpet.comparator64[tn];
92: if ( timer_is_periodic(h, tn) )
93: {
94: /* update comparator by number of periods elapsed since last update */
95: uint64_t period = h->hpet.period[tn];
96: if (period)
97: {
98: elapsed = hpet_read_maincounter(h) + period - 1 - comparator;
99: comparator += (elapsed / period) * period;
100: h->hpet.comparator64[tn] = comparator;
101: }
102: }
104: /* truncate if timer is in 32 bit mode */
105: if ( timer_is_32bit(h, tn) )
106: comparator = (uint32_t)comparator;
107: h->hpet.timers[tn].cmp = comparator;
108: return comparator;
109:}
so on line 98:
elapsed = 67752 + 62500 - 1 - 255252
bc
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
67752 + 62500 - 1 - 255252
-125001
Or in hex: 0xFFFFFFFFFFFE17B7
Next:
-125001/62500
-2
-2*62500
-125000
So on line 99 the comparator is changed by -125000.
I.E. the value written is not the value read.
-Don Slutz
> Jan
>
>
next prev parent reply other threads:[~2014-04-15 18:11 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-08 14:24 [PATCH v2 00/10] Prevent one cause of "MP-BIOS bug: 8254 timer"... message from linux Don Slutz
2014-04-08 14:24 ` [PATCH v2 01/10] hvm/hpet: Add manual unit test code Don Slutz
2014-04-09 16:08 ` Jan Beulich
2014-04-09 18:35 ` Don Slutz
2014-04-10 6:11 ` Jan Beulich
2014-04-11 2:53 ` Don Slutz
2014-04-11 7:45 ` Jan Beulich
2014-04-11 11:57 ` [PATCH optional " Don Slutz
2014-04-11 12:09 ` Jan Beulich
2014-04-11 12:48 ` Don Slutz
2014-04-11 15:14 ` Jan Beulich
2014-04-11 17:40 ` Don Slutz
2014-04-14 7:40 ` Jan Beulich
2014-04-14 17:29 ` test_x86_emulator (was Re: [PATCH optional v2 01/10] hvm/hpet: Add manual unit test code.) Don Slutz
2014-04-15 6:49 ` test_x86_emulator Jan Beulich
2014-04-15 14:24 ` test_x86_emulator Don Slutz
2014-04-16 8:26 ` test_x86_emulator Jan Beulich
2014-04-16 9:32 ` test_x86_emulator Keir Fraser
2014-04-16 15:21 ` test_x86_emulator Don Slutz
2014-04-08 14:24 ` [PATCH v2 02/10] hvm/hpet: Only call guest_time_hpet(h) one time per action Don Slutz
2014-04-14 14:31 ` Jan Beulich
2014-04-14 17:38 ` Don Slutz
2014-04-08 14:24 ` [PATCH v2 03/10] hvm/hpet: Only set comparator or period not both Don Slutz
2014-04-14 14:58 ` Jan Beulich
2014-04-14 22:53 ` Don Slutz
2014-04-15 6:59 ` Jan Beulich
2014-04-16 4:06 ` Don Slutz
2014-04-08 14:24 ` [PATCH v2 04/10] hvm/hpet: In hpet_save, correctly compute mc64 Don Slutz
2014-04-08 14:24 ` [PATCH v2 05/10] hvm/hpet: Init comparator64 like comparator Don Slutz
2014-04-08 14:24 ` [PATCH v2 06/10] hvm/hpet: comparator can only change when master clock is enabled Don Slutz
2014-04-14 15:07 ` Jan Beulich
2014-04-14 19:50 ` Don Slutz
2014-04-15 7:05 ` Jan Beulich
2014-04-15 15:53 ` Don Slutz
2014-04-15 16:14 ` Jan Beulich
2014-04-15 18:11 ` Don Slutz [this message]
2014-04-16 8:42 ` Jan Beulich
2014-04-08 14:24 ` [PATCH v2 07/10] hvm/hpet: Call hpet_get_comparator during hpet_save Don Slutz
2014-04-14 15:13 ` Jan Beulich
2014-04-15 0:21 ` Don Slutz
2014-04-15 7:06 ` Jan Beulich
2014-04-15 14:18 ` Don Slutz
2014-04-08 14:24 ` [PATCH v2 08/10] hvm/hpet: Prevent master clock equal to comparator while enabled Don Slutz
2014-04-08 14:24 ` [PATCH v2 09/10] hvm/hpet: Correctly limit period to a maximum Don Slutz
2014-04-08 14:24 ` [PATCH v2 10/10] hvm/hpet: handle 1st period special Don Slutz
2014-04-14 15:27 ` Jan Beulich
2014-04-15 0:21 ` Don Slutz
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=534D764A.7010606@terremark.com \
--to=dslutz@verizon.com \
--cc=JBeulich@suse.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xen.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).