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