Re: [Qemu-devel] Poking a sun4v machine

["Andreas Färber" <afaerber@suse.de>]

Am 30.04.2012 19:38, schrieb Artyom Tarasenko:
> On Mon, Apr 30, 2012 at 7:15 PM, Andreas Färber <afaerber@suse.de> wrote:
>> Am 30.04.2012 18:39, schrieb Artyom Tarasenko:
>>> Tried to boot QEMU Niagara machine with the firmware from the
>>> OpenSPARC T1 emulator ( www.opensparc.net/opensparc-t1/download.html )
>>> , and it dies very early.
>>> The reason: in translate.c
>>>
>>> #define hypervisor(dc) (dc->mem_idx == MMU_HYPV_IDX)
>>> #define supervisor(dc) (dc->mem_idx >= MMU_KERNEL_IDX)
>>>
>>> and the dc->mem_idx is initialized like this:
>>>
>>>     if (env1->tl > 0) {
>>>         return MMU_NUCLEUS_IDX;
>>>     } else if (cpu_hypervisor_mode(env1)) {
>>>         return MMU_HYPV_IDX;
>>>     } else if (cpu_supervisor_mode(env1)) {
>>>         return MMU_KERNEL_IDX;
>>>     } else {
>>>         return MMU_USER_IDX;
>>>     }
>>>
>>> Which seems to be conceptually incorrect. After reset tl == MAXTL, but
>>> still super- and hyper-visor bits are set, so both supervisor(dc) and
>>> hypervisor(dc) must return 1 which is impossible in the current
>>> implementation.
>>>
>>> What would be the proper way to fix it? Make mem_idx bitmap, add two
>>> more variables to DisasContext, or ...?
>>>
>>> Some other findings/questions:
>>>
>>>     /* Sun4v generic Niagara machine */
>>>     {
>>>         .default_cpu_model = "Sun UltraSparc T1",
>>>         .console_serial_base = 0xfff0c2c000ULL,
>>>
>>> Where is this address coming from? The OpenSPARC Niagara machine has a
>>> "dumb serial" at 0x1f10000000ULL.
>>>
>>> And the biggest issue: UA2005 (as well as UA2007) describe a totally
>>> different format for a MMU TTE entry than the one sun4u CPU are using.
>>> I think the best way to handle it would be splitting off Niagara
>>> machine, and #defining MMU bits differently for sun4u and sun4v
>>> machines.
>>>
>>> Do we the cases in qemu where more than two (qemu-system-xxx and
>>> qemu-system-xxx64) binaries are produced?
>>> Would the name qemu-system-sun4v fit the naming convention?
>>
>> We have such a case for ppc (ppcemb) and it is kind of a maintenance
>> nightmare - I'm working towards getting rid of it with my QOM CPU work.
>> Better avoid it for sparc in the first place.
>>
>> Instead, you should add a callback function pointer to SPARCCPUClass
>> that you initialize based on CPU model so that is behaves differently at
>> runtime rather than at compile time.
>> Or if it's just about the class_init then after the Hard Freeze I can
>> start polishing my subclasses for sparc so that you can add a special
>> class_init for Niagara.
> 
> But this would mean that the defines from
> #define TTE_NFO_BIT (1ULL << 60)
> to
> #define TTE_PGSIZE(tte)     (((tte) >> 61) & 3ULL)
> 
> inclusive would need to be replaced with functions and variables?
> Sounds like a further performance regression for sun4u?

First of all, I wouldn't use the term performance regression for a
target such as sparc64 that has never really worked before. ;-)

I don't know the details of the SPARC implementation or architecture.
What I am telling you is that there are ways to implement sun4u and
sun4v inside one executable; whether you use a new function or extend a
macro with an additional parameter is up to you and Blue. My guess is
that unlike ARM you won't need to mix different cores at runtime for the
time being.

In ARM we have a macro IS_M() that distinguishes between the Cortex-M
and Cortex-A families rather than moving Cortex-M to its own executable.
The Freescale Vybrid MCUs are going to combine the two in one SoC, i.e.
in one qemu-system-arm executable simultaneously.

> And would it be possible to have a different register set for an
> inherited SPARCCPUClass ?

You can add new state fields to an inherited SPARCCPU.

If you need them in TCG as offsets from env, then CPUSPARCState might be
an easier place to add them but there you cannot distinguish between the
models.

To an inherited SPARCCPUClass you can add fields for saving constant,
e.g., reset values for registers of the model.

The unanswered question is whether SPARC should follow the x86 model
with declarative (and user-specified) definitions (in that case
extending SPARCCPUClass) or the ARM model with imperative per-model init
functions (in that case probably not extending SPARCCPU at all).

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg