Date: Thu, 24 Sep 2015 21:56:04 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: Alexey Dokuchaev <danfe@FreeBSD.org>, "freebsd-sparc64@freebsd.org" <freebsd-sparc64@freebsd.org> Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <20150924195603.GT18789@alchemy.franken.de> In-Reply-To: <56044B9C.8030105@ilande.co.uk> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150924195603.GT18789>