On Tue, May 1, 2012 at 10:35 AM, Andreas Färber <afaer...@suse.de> wrote: > Am 30.04.2012 19:38, schrieb Artyom Tarasenko: >> 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? > > 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