Re: [Qemu-devel] Poking a sun4v machine

[Artyom Tarasenko]

On Tue, May 1, 2012 at 10:35 AM, Andreas Färber <address@hidden> wrote:
> Am 30.04.2012 19:38, schrieb Artyom Tarasenko:
>> On Mon, Apr 30, 2012 at 7:15 PM, Andreas Färber <address@hidden> 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. ;-)

Well, it works good enough for me. ;-) Also until the recent PCI
changes it was able to boot HelenOS out of the box.

> 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.

Can the inheritance hierarchy have any depth? Then we could think of
having SPARC->(SPARC32,SPARC64)
and SPARC64 -> (sun4u, sun4v, Fujitsu). But I still don't see the
advantages of having it configurable at runtime.

> 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



-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu