From owner-freebsd-sparc64@freebsd.org Thu Sep 24 19:56:13 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D5C4A087A9 for ; Thu, 24 Sep 2015 19:56:13 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B8A891F83; Thu, 24 Sep 2015 19:56:12 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id t8OJu4KB015499 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Sep 2015 21:56:04 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id t8OJu4K3015495; Thu, 24 Sep 2015 21:56:04 +0200 (CEST) (envelope-from marius) Date: Thu, 24 Sep 2015 21:56:04 +0200 From: Marius Strobl To: Mark Cave-Ayland Cc: Alexey Dokuchaev , "freebsd-sparc64@freebsd.org" Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <20150924195603.GT18789@alchemy.franken.de> References: <20150916211914.GD18789@alchemy.franken.de> <20150917082817.GA71811@FreeBSD.org> <55FBB662.4080708@ilande.co.uk> <20150919211420.GK18789@alchemy.franken.de> <55FDEA3C.1010804@ilande.co.uk> <20150920043630.GA36162@FreeBSD.org> <20150922221404.GA81100@alchemy.franken.de> <560260A9.9010505@ilande.co.uk> <20150923204336.GO18789@alchemy.franken.de> <56044B9C.8030105@ilande.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56044B9C.8030105@ilande.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Thu, 24 Sep 2015 21:56:04 +0200 (CEST) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 19:56:13 -0000 On Thu, Sep 24, 2015 at 08:14:36PM +0100, Mark Cave-Ayland wrote: > On 23/09/15 21:43, Marius Strobl wrote: > > > On Wed, Sep 23, 2015 at 09:19:53AM +0100, Mark Cave-Ayland wrote: > >> > >> I've had a quick look through the relevant PDFs and the definitions I > >> have for tick/stick are this: > >> > >> tick: > >> bit 63: NPT (Non-Privileged Trap enable - defaults to 1) > >> bits 62 - 0: CPU cycle counter > >> > >> tick_cmpr: > >> bit 63: Interrupt disable (1 = no interrupt) > >> bits 62 - 0: counter compare value > >> > >> stick: > >> bit 63: Reserved (reads 0, no write) > >> bits 62 - 0: stick register count value > > > > I cannot confirm that, the specification for the first sun4u CPU > > having a %stick register (UltraSPARC III, see 1, p. 6-105) up to > > the latest architecture specification (see 2, p. 60) say that bit > > 32 of %stick is NPT, just as with %tick. Same for the specification > > the Fujitsu SPARC64 processors follow (3, p. 90). > > Interesting. The document I'm referring to in my local collection is the > UltraSPARC IIe specification which you can find a copy at > http://www.coris.org.uk/misc/Sundocs/USIIe_ext_1.1.pdf (see page 29). I > don't see this as necessarily being a conflict, it just seems that the > IIe allows unprivileged access to %stick. Err, we are taking about different STICK registers. The one I was referring to is the ASR24 CPU register, i. e. the thing QEMU tries to emulate. It works akin to TICK (%tick in GCC assembly) but is driven by a different clock in real machines. The STICK frequency is guaranteed to be the same across all CPUs (which unfortunately doesn't imply that the STICK registers are synchronized). ASR24 and the accompanying compare register (ASR25) were introduced with the UltraSPARC III as systems built on these were the first sun4u machines allowing to mix different CPU speeds (which results in different TICK clocks). UltraSPARC IIe had sort of a predecessor to that STICK register. The main difference is that the UltraSPARC IIe version has been implemented in I/O space (see page 42 of the PDF file you are citing), IIRC as part of the Hummingbird host-PCI-bridge built into the actual UltraSPARC IIe chips. That also explains why it has no NPT functionality (and why the UltraSPARC IIe user manual may be confusing as it doesn't solely document the CPU core; I think this isn't that different with UltraSPARC IIi, though). The UltraSPARC IIe STICK register was introduced to ease time keeping when the CPU clock is throttled (referred to as E-Star operation here; STICK frequency is unaffected by it). In short: You can ignore the UltraSPARC IIe documentation for the STICK CPU register QEMU tries to emulate. Marius