WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: Question on virtual HPET's behavior

To: "Shan, Haitao" <haitao.shan@xxxxxxxxx>
Subject: [Xen-devel] Re: Question on virtual HPET's behavior
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 27 Dec 2007 09:17:02 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 27 Dec 2007 01:10:39 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <823A93EED437D048963A3697DB0E35DEFD37FE@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchHvBbtVyfWSh9jR1ygGG/txsMeigACoOB5AABrrCAAAYcR6wAS1sMgABPfQs0=
Thread-topic: Question on virtual HPET's behavior
User-agent: Microsoft-Entourage/11.3.6.070618
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
1226 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