PCI range checking under qemu-system-sparc64

[Mark Cave-Ayland]

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?

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.


ATB,

Mark.