From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [Patch 4/4] x86/hpet: Don't clear reserved bits in the General Configuration Register Date: Mon, 7 Oct 2013 15:02:00 +0100 Message-ID: <5252BED8.7040102@citrix.com> References: <1381152381-19744-1-git-send-email-andrew.cooper3@citrix.com> <1381152381-19744-5-git-send-email-andrew.cooper3@citrix.com> <5252D97A02000078000F946B@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VTBNs-0000ob-M8 for xen-devel@lists.xenproject.org; Mon, 07 Oct 2013 14:02:04 +0000 In-Reply-To: <5252D97A02000078000F946B@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 07/10/13 14:55, Jan Beulich wrote: >>>> On 07.10.13 at 15:26, Andrew Cooper wrote: >> It is a violation of the specification. >> >> The reserved bits in the General Configuration Register, unlike all other >> reserved bits I have found in the spec, are specified as 'must never be >> changed by the OS'. > Mind pointing out where exactly you found this? I only find the > usual "should not modify" statements, and it is really unclear > whether leaving the bits alone is more compatible than clearing > them (since a bit of unknown function being set may easily mean > the HPET behaves in a way we don't expect). > > Jan > Hpet spec 1-0a.pdf Page 12 "General Configuration Register Bit Definitions" For bits 63:2, (ignoring the spec reserved vs firmware reserved bits), the requirement states: "In order to preserve usage of these bits in the future, software should not modify the value in these bits until they are defined. This is done by doing a =93read-modify-write=94 to this register." In most cases Xen does correctly perform a read-modify-write, but not on initialize examination of the hpet where it blindly tries to clear bits it doesn't understand. I did find it strange at the difference in the spec; All other reserved bits I can find are specified as "must write 0". ~Andrew