Re: [PATCH qemu] spapr: Force 32bit when resetting a core

[BALATON Zoltan]

On Fri, 14 Jan 2022, Cédric Le Goater wrote:
> On 1/10/22 03:52, Alexey Kardashevskiy wrote:
> > On 08/01/2022 00:39, Greg Kurz wrote:
> > > On Fri, 7 Jan 2022 23:19:03 +1100
> > > David Gibson <david@gibson.dropbear.id.au> wrote:
> > >
> > > > On Fri, Jan 07, 2022 at 12:57:47PM +0100, Greg Kurz wrote:
> > > > > On Fri, 7 Jan 2022 18:24:23 +1100
> > > > > Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> > > > >
> > > > > > "PowerPC Processor binding to IEEE 1275" says in
> > > > > > "8.2.1. Initial Register Values" that the initial state is defined as
> > > > > > 32bit so do it for both SLOF and VOF.
> > > > > >
> > > > > > This should not cause behavioral change as SLOF switches to 64bit very
> > > > > > early anyway.
> > > > >
> > > > > Only one CPU goes through SLOF. What about the other ones, including
> > > > > hot plugged CPUs ?
> > > >
> > > > Those will be started by the start-cpu RTAS call which has its own
> > > > semantics.
> > >
> > > Ah indeed, there's code in linux/arch/powerpc/kernel/head_64.S to switch
> > > secondaries to 64bit... but then, as noted by Cedric, ppc_cpu_reset(),
> > > which is called earlier sets MSR_SF but the changelog of commit 
> > > 8b9f2118ca40
> > > doesn't provide much details on the motivation. Any idea ?
> >
> > https://patchwork.kernel.org/project/qemu-devel/patch/1458121432-2855-1-git-send-email-lvivier@redhat.com/
> >
> > this is probably it:
> >
> > ===
> > Reset is properly defined as an exception (0x100). For exceptions, the
> > 970MP user manual for example says:
> >
> > 4.5 Exception Definitions
> > When an exception/interrupt is taken, all bits in the MSR are set to
> > ‘0’, with the following exceptions:
> > • Exceptions always set MSR[SF] to ‘1’.
> > ===
> >
> > but it looks like the above is about emulation bare metal 970 rather than 
> > pseries VCPU so that quote does not apply to spapr.
>
> Yes, more info here :
>
>  
> https://patchwork.kernel.org/project/qemu-devel/patch/1458121432-2855-1-git-send-email-lvivier@redhat.com/
>
> mac99+970 only boots with a 64bit kernel. 32bit are not supported because
> of the use of the rfi instruction which was removed in v2.01. 32bit user
> space is supported though.
>
> However I was not able to build a disk with a compatible boot partition
> for OpenBIOS. The above support only applies for kernel loaded in memory.

Not sure it's related or helpful but I've managed to install Adélie Linux 
(which still has official support for PPC Macs) on qemu-system-ppc64 -M 
mac99,via=pmu a while ago. Here's a thread about my experiences with 
Adélie Linux:

https://lists-old.adelielinux.org/hyperkitty/list/adelie-devel@lists.adelielinux.org/thread/CNWIYZCFN7XDBSDCZDVIUE3SXE2EX6YF/index.html

but that mentions qemu-system-ppc and ppc32 version so this was before the 
ppc64 install which may be a newer Adélie version that I had no such 
problem starting. Ar least I did not need the patched OpenBIOS for ppc64. 
I think that version worked with qemu-system-ppc64 and could just install 
it following the manual install described in the Adélie docs:

https://git.adelielinux.org/adelie/docs/-/wikis/Quick-Start-Guides/Installation

To boot the installed system I had to type "boot hd:2,\grub" as it did not 
find the boot partition for some reason (maybe because not preserving 
nvram variables).

The installed disk has these partitions:
1: Apple partition map
2. boot (HFS)
3: root (ext4)

This was a while ago so I don't remember the details but I think it worked 
for the G5 mac99 without much problem.

Regards,
BALATON Zoltan