Date: Sun, 11 Oct 2015 23:09:12 +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: <20151011210912.GA43837@alchemy.franken.de> In-Reply-To: <56087660.6070408@ilande.co.uk> References: <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> <20150924195603.GT18789@alchemy.franken.de> <56087660.6070408@ilande.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 28, 2015 at 12:06:08AM +0100, Mark Cave-Ayland wrote: > On 24/09/15 20:56, Marius Strobl wrote: > > > 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. > > Now I see - I didn't quite appreciate the difference between IIe and II > %stick registers. Given that the default processor for QEMU is the TI > UltraSPARC IIi, does that mean that %stick should even be implemented in > the default configuration? Like I wrote above, the CPU-register-based STICK counter - which QEMU tries to emulate - was introduced with USIII. It also was brought over to sun4v, though, which additionally grew a HSTICK (Hyperprivileged System Tick, i. e. for use by the hypervisor). My understanding is target-sparc/translate.c is shared between the sun4u and sun4v emulation of QEMU, which explains why that source file implements all of TICK, STICK and HSTICK code. The I/O-space-based STICK counter in turn is specific to USIIe. So, no, as long as the sun4u support of QEMU consists of USIIi emulation only - which still is the case AFAICT -, there's no need to implement the I/O-space-based STICK counter in the default configuration. In fact, due to the limitation to USIIi, the sun4u emulation of QEMU currently would solely need to implement TICK support. I just wanted to point out the obvious bugs present in all of TICK, STICK and HSTICK CPU register code of QEMU but also the erroneous inconsistencies between these implementations. I still don't have an explanation for the incorrect behavior, i. e. the TICK compare interrupt not firing due to the disable bit somehow being stuck in QEMU, when trying to run FreeBSD, however. > In other news, as of this weekend I've finally got my FreeBSD VM set up > with -CURRENT and generating a SPARC64 .iso for test. I've got a basic > patchset for kb_ps2 and kdmouse that attaches under all of the BSDs but > causes my test Linux kernel to reference a NULL pointer. I'll post the > patchset onto the OpenBIOS list and a test binary as soon as I have > something that passes all of my local tests. > That's nice; modulo the NULL pointer dereference that is, of course :) Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151011210912.GA43837>