| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: Question on virtual HPET's behavior
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@xxxxxxxxx> 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@xxxxxxxxxxxx]
Sent: 2007年12月26日 22:49
To: Shan, Haitao
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home