Hi, Keir,
When reading vHPET''s code, I find the following in hpet_write function:
case HPET_T2_CMP:
tn = (addr - HPET_T0_CMP) >> 5;
if ( timer_is_32bit(h, tn) )
new_val = (uint32_t)new_val;
if ( !timer_is_periodic(h, tn) ||
(h->hpet.timers[tn].config & HPET_TN_SETVAL) )
h->hpet.timers[tn].cmp = new_val;
else
h->hpet.period[tn] = new_val;
Here hpet.period is updated only when timer 0 is in periodic mode and
SET_VAL is not set. But from HPET spec 1.0a, I can not find the reason.
The spec provides a recommended sequence to reset main counter and
comparator.
If the software resets the main counter, the value in the comparator''s
value register needs to reset as well. This can be done by setting the
n_VAL_SET_CNF bit. Again, to avoid race conditions, this should be done
with the main counter halted. The following usage model is expected:
1) Software clears the GLOBAL_ENABLE_CNF bit to prevent any interrupts
2) Software Clears the main counter by writing a value of 00000000h to
it.
3) Software sets the TIMER0_VAL_SET_CNF bit.
4) Software writes the new value in the TIMER0_COMPARATOR_VAL register
5) Software sets the GLOBAL_ENABLE_CNF bit to enable interrupts.
What will the result is system software only writes the comparator once
after set SET_VAL like the above sequence?
Can you give me some hints? Thanks in advance!
Best Regards
Haitao Shan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
My reading of the (really bad) specification doc is that in periodic mode writes to the comparator register change the period only, unless VAL_SET_CNF is set in which case only the comparator counter value is set. The Linux HPET code agrees with this interpretation it writes to the comparator register twice. Do you have an example of an OS that assumes different HPET behaviour? -- Keir On 26/12/07 12:37, "Shan, Haitao" <haitao.shan@intel.com> wrote:> Here hpet.period is updated only when timer 0 is in periodic mode and SET_VAL > is not set. But from HPET spec 1.0a, I can not find the reason. The spec > provides a recommended sequence to reset main counter and comparator. > > If the software resets the main counter, the value in the comparator¹s value > register needs to reset as well. This can be done by setting the > n_VAL_SET_CNF bit. Again, to avoid race conditions, this should be done with > the main counter halted. The following usage model is expected: > > 1) Software clears the GLOBAL_ENABLE_CNF bit to prevent any interrupts > > 2) Software Clears the main counter by writing a value of 00000000h to it. > > 3) Software sets the TIMER0_VAL_SET_CNF bit. > > 4) Software writes the new value in the TIMER0_COMPARATOR_VAL register > > 5) Software sets the GLOBAL_ENABLE_CNF bit to enable interrupts. > > What will the result is system software only writes the comparator once after > set SET_VAL like the above sequence? > > Can you give me some hints? Thanks in advance!_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
No. I did not see such an OS. My concern is: When VAL_SET_CNF is set, do the two registers all get updated? The spec does provide information. From our tests, if you strictly follow the sequence attached in my first mail, the comparator can keep increasing normally. With virtual HPET, it is not true, because period is not considered to be set by only one write. Our tests are carried out on ICH9. This leads me to confusion. Which one is the right behavior? Writing twice should guarantee the correctness, but is it a must? Haitao Shan ________________________________ From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] Sent: 2007年12月26日 21:53 To: Shan, Haitao Cc: xen-devel@lists.xensource.com Subject: Re: Question on virtual HPET''s behavior My reading of the (really bad) specification doc is that in periodic mode writes to the comparator register change the period only, unless VAL_SET_CNF is set in which case only the comparator counter value is set. The Linux HPET code agrees with this interpretation - it writes to the comparator register twice. Do you have an example of an OS that assumes different HPET behaviour? -- Keir On 26/12/07 12:37, "Shan, Haitao" <haitao.shan@intel.com> wrote: Here hpet.period is updated only when timer 0 is in periodic mode and SET_VAL is not set. But from HPET spec 1.0a, I can not find the reason. The spec provides a recommended sequence to reset main counter and comparator. If the software resets the main counter, the value in the comparator’s value register needs to reset as well. This can be done by setting the n_VAL_SET_CNF bit. Again, to avoid race conditions, this should be done with the main counter halted. The following usage model is expected: 1) Software clears the GLOBAL_ENABLE_CNF bit to prevent any interrupts 2) Software Clears the main counter by writing a value of 00000000h to it. 3) Software sets the TIMER0_VAL_SET_CNF bit. 4) Software writes the new value in the TIMER0_COMPARATOR_VAL register 5) Software sets the GLOBAL_ENABLE_CNF bit to enable interrupts. What will the result is system software only writes the comparator once after set SET_VAL like the above sequence? Can you give me some hints? Thanks in advance! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Shan, Haitao
2007-Dec-26 14:23 UTC
RE: [Xen-devel] RE: Question on virtual HPET''s behavior
Sorry, I missed one word. The spec does *not* provide information. ________________________________ From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Shan, Haitao Sent: 2007年12月26日 22:19 To: Keir Fraser Cc: xen-devel@lists.xensource.com Subject: [Xen-devel] RE: Question on virtual HPET''s behavior No. I did not see such an OS. My concern is: When VAL_SET_CNF is set, do the two registers all get updated? The spec does provide information. From our tests, if you strictly follow the sequence attached in my first mail, the comparator can keep increasing normally. With virtual HPET, it is not true, because period is not considered to be set by only one write. Our tests are carried out on ICH9. This leads me to confusion. Which one is the right behavior? Writing twice should guarantee the correctness, but is it a must? Haitao Shan ________________________________ From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] Sent: 2007年12月26日 21:53 To: Shan, Haitao Cc: xen-devel@lists.xensource.com Subject: Re: Question on virtual HPET''s behavior My reading of the (really bad) specification doc is that in periodic mode writes to the comparator register change the period only, unless VAL_SET_CNF is set in which case only the comparator counter value is set. The Linux HPET code agrees with this interpretation - it writes to the comparator register twice. Do you have an example of an OS that assumes different HPET behaviour? -- Keir On 26/12/07 12:37, "Shan, Haitao" <haitao.shan@intel.com> wrote: Here hpet.period is updated only when timer 0 is in periodic mode and SET_VAL is not set. But from HPET spec 1.0a, I can not find the reason. The spec provides a recommended sequence to reset main counter and comparator. If the software resets the main counter, the value in the comparator’s value register needs to reset as well. This can be done by setting the n_VAL_SET_CNF bit. Again, to avoid race conditions, this should be done with the main counter halted. The following usage model is expected: 1) Software clears the GLOBAL_ENABLE_CNF bit to prevent any interrupts 2) Software Clears the main counter by writing a value of 00000000h to it. 3) Software sets the TIMER0_VAL_SET_CNF bit. 4) Software writes the new value in the TIMER0_COMPARATOR_VAL register 5) Software sets the GLOBAL_ENABLE_CNF bit to enable interrupts. What will the result is system software only writes the comparator once after set SET_VAL like the above sequence? Can you give me some hints? Thanks in advance! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
The only reason I can think of why Linux writes twice, and indeed has a udelay(1) between the two writes these days, is because some hardware implementations only allow access to one of comparator and period on each write, and never both. But the ICH9 behaviour doesn¹t appear to violate the spec either (in fact possibly the spec seems more in line with ICH9 behaviour). Perhaps you can ask the right team within Intel what the intended semantics is, or whether it is defined at all? -- Keir On 26/12/07 14:19, "Shan, Haitao" <haitao.shan@intel.com> wrote:> No. I did not see such an OS. My concern is: When VAL_SET_CNF is set, do the > two registers all get updated? The spec does provide information. From our > tests, if you strictly follow the sequence attached in my first mail, the > comparator can keep increasing normally. With virtual HPET, it is not true, > because period is not considered to be set by only one write. Our tests are > carried out on ICH9. > This leads me to confusion. Which one is the right behavior? Writing twice > should guarantee the correctness, but is it a must?_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thanks, Keir! I just find one HW implementation which only allows one write to one register. That should be the reason for kernel’s approach. Do you think we can change the virtual HPET part? Changing device model to one write approach won’t break two writes approach like kernel, while it offers support in case only one write exists? Haitao ________________________________ From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] Sent: 2007年12月26日 22:49 To: Shan, Haitao Cc: xen-devel@lists.xensource.com Subject: Re: Question on virtual HPET''s behavior The only reason I can think of why Linux writes twice, and indeed has a udelay(1) between the two writes these days, is because some hardware implementations only allow access to one of comparator and period on each write, and never both. But the ICH9 behaviour doesn’t appear to violate the spec either (in fact possibly the spec seems more in line with ICH9 behaviour). Perhaps you can ask the right team within Intel what the intended semantics is, or whether it is defined at all? -- Keir On 26/12/07 14:19, "Shan, Haitao" <haitao.shan@intel.com> wrote: No. I did not see such an OS. My concern is: When VAL_SET_CNF is set, do the two registers all get updated? The spec does provide information. From our tests, if you strictly follow the sequence attached in my first mail, the comparator can keep increasing normally. With virtual HPET, it is not true, because period is not considered to be set by only one write. Our tests are carried out on ICH9. This leads me to confusion. Which one is the right behavior? Writing twice should guarantee the correctness, but is it a must? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Many AMD systems have the current Xen behaviour. See the mail thread at <http://lkml.org/lkml/2005/2/3/114> for example. I wouldn’t change the code unless there was a definitive answer on correct behaviour from someone involved in the specification, or if we found that changing the emulation behaviour actually fixed a bug. -- Keir On 26/12/07 23:58, "Shan, Haitao" <haitao.shan@intel.com> wrote:> Thanks, Keir! > I just find one HW implementation which only allows one write to one register. > That should be the reason for kernel’s approach. Do you think we can change > the virtual HPET part? Changing device model to one write approach won’t break > two writes approach like kernel, while it offers support in case only one > write exists? > > Haitao > > > > From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] > Sent: 2007年12月26日 22:49 > To: Shan, Haitao > Cc: xen-devel@lists.xensource.com > Subject: Re: Question on virtual HPET''s behavior > > The only reason I can think of why Linux writes twice, and indeed has a > udelay(1) between the two writes these days, is because some hardware > implementations only allow access to one of comparator and period on each > write, and never both. But the ICH9 behaviour doesn’t appear to violate the > spec either (in fact possibly the spec seems more in line with ICH9 > behaviour). > > Perhaps you can ask the right team within Intel what the intended semantics > is, or whether it is defined at all? > > -- Keir > > On 26/12/07 14:19, "Shan, Haitao" <haitao.shan@intel.com> wrote: > No. I did not see such an OS. My concern is: When VAL_SET_CNF is set, do the > two registers all get updated? The spec does provide information. From our > tests, if you strictly follow the sequence attached in my first mail, the > comparator can keep increasing normally. With virtual HPET, it is not true, > because period is not considered to be set by only one write. Our tests are > carried out on ICH9. > This leads me to confusion. Which one is the right behavior? Writing twice > should guarantee the correctness, but is it a must? > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel