Re: [RFC PATCH 0/2] QEMU/openbios: PPC Software TLB support in the G4 family

["Cédric Le Goater" <clg@kaod.org>]

On 11/29/21 16:28, Fabiano Rosas wrote:
> Cédric Le Goater <clg@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.

  
Thanks,

C.