Cédric Le Goater <c...@kaod.org> writes: > On 11/29/21 16:28, Fabiano Rosas wrote: >> Cédric Le Goater <c...@kaod.org> writes: >> >>>>> Right. If we're doing this to say "I can boot a kernel with a 7450 cpu in >>>>> QEMU" but >>>>> the implementation is different from real hardware, then I'm not sure >>>>> what the real >>>>> value is. That effectively leaves option b) if someone is willing to do >>>>> the work, or >>>>> as you say to simply remove the code from QEMU. >>>> >>>> Yeah, that is a good point. Although the software TLB is well contained, >>>> so we could certainly document that our 7450s don't have that feature >>>> and call it a day. Does QEMU have any policy on how much of a machine is >>>> required to be implemented? >>>> >>>> I am more inclined to apply c) for now as I said, just to have some code >>>> running on the CPU and maybe document in a gitlab issue that we're >>>> lacking the runtime switch and eventually implement that. It's not like >>>> this is high traffic code anyway. It has been broken for 10+ years. >>>> >>>> That said, if Cédric and Daniel see more value in moving the 7450s to >>>> the POWERPC_MMU_32B I won't oppose. >>> >>> I am in favor of dropping unused code in QEMU and keeping the CPUs for >>> which we have support in Linux using the POWERPC_MMU_32B in QEMU and the >>> openbios patch. If we need SoftTLB support for the 74x CPUs in QEMU, we >>> can always dig in the history. >> >> Ack. I'll send a v2. >> >>> >>> We can give FreeBSB a try also since they had support for the G4 : >>> >>> https://people.freebsd.org/~arved/stuff/minimac >>> >>> >>> With the openbios patch, Linux boots fine under 7450, 7455, 7447 CPUs. >>> >>> Under 7448, it drops in xmon with a : >>> >>> kernel tried to execute exec-protected page (c07fdd98) - exploit attempt? >>> (uid: 0) >>> BUG: Unable to handle kernel instruction fetch >>> Faulting instruction address: 0xc07fdd98 >>> Vector: 400 (Instruction Access) at [f1019d30] >>> pc: c07fdd98: __do_softirq+0x0/0x2f0 >>> lr: c00516a4: irq_exit+0xbc/0xf8 >>> sp: f1019df0 >>> msr: 10001032 >>> current = 0xc0d00000 >>> pid = 1, comm = swapper >> >> I see two possible issues: >> >> 1) The 7448 is configured as a 7400 in QEMU (cpu-models.c), so it will >> behave differently from the 7450s. The user manual seems to indicate it >> is closer to a 7445 than a 7400. We need to double check what is correct. >> >> 2) OpenBIOS already has support for the 7448 PVR without my patch, but >> given that no other cpu of the 7450 family is supported, I'd say this is >> accidental. The mask that OpenBIOS uses for e600/MPC86xx is: >> >> .iu_version = 0x80040000, >> .name = "PowerPC,MPC86xx", >> >> And the verification: >> >> iu_version = mfpvr() & 0xffff0000; >> >> for (i = 0; i < sizeof(ppc_defs) / sizeof(struct cpudef); i++) { >> if (iu_version == ppc_defs[i].iu_version) >> return &ppc_defs[i]; >> } >> printk("Unknown cpu (pvr %x), freezing!\n", iu_version); >> >> But QEMU says the PVRs are as follows: >> >> CPU_POWERPC_e600 = 0x80040010, >> #define CPU_POWERPC_MPC8610 CPU_POWERPC_e600 >> #define CPU_POWERPC_MPC8641 CPU_POWERPC_e600 >> #define CPU_POWERPC_MPC8641D CPU_POWERPC_e600 >> >> CPU_POWERPC_7448_v10 = 0x80040100, >> CPU_POWERPC_7448_v11 = 0x80040101, >> CPU_POWERPC_7448_v20 = 0x80040200, >> CPU_POWERPC_7448_v21 = 0x80040201, >> >> So by applying the mask, OpenBIOS is matching both 0x80040100 and >> 0x80040010 when it looks like it only wants to match the latter. > > Hello, > > a quick status on how QEMU has evolved regarding this topic. > > We have merged : > > a09410ed1fb8 ("target/ppc: Remove the software TLB model of 7450 CPUs") > > and switched MMU model to POWERPC_MMU_32B in : > > 1da666cd8e79 ("target/ppc: Disable software TLB for the 7450 family") > > With the two patches of this series, we can boot the latest linux on all > 7450 CPUs. With an extra small fix on the CPU table, 7448 boots.
A small correction, we only need OpenBIOS to include patch 2: "ppc: Add PVRs for the MPC7450 family".
