On Mon, Apr 30, 2012 at 7:15 PM, Andreas Färber <afaer...@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?

And would it be possible to have a different register set for an
inherited SPARCCPUClass ?
Also trap handling and related cpu registers behavior has to be quite different.

Artyom

> Helpers such as cpu_hypervisor_mode() will need to be changed to take a
> SPARCCPU *cpu rather than CPUSPARCState *env argument; as an interim
> solution sparc_env_get_cpu() can be used. (examples on the list for sh4)
>
> 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

Reply via email to