Re: [PATCH qemu v19] spapr: Implement Open Firmware client interface

[BALATON Zoltan]

On Mon, 17 May 2021, Alexey Kardashevskiy wrote:
> On 5/17/21 09:34, BALATON Zoltan wrote:
> > On Sat, 15 May 2021, BALATON Zoltan wrote:
> > > On Sat, 15 May 2021, BALATON Zoltan wrote:
> > > > On Thu, 22 Apr 2021, Alexey Kardashevskiy wrote:
>
> [snip]
>
> > > > vof_claim virt=0x0 size=0xc38 align=0x0 => 0x0
> > > > vof_claim virt=0x0 size=0x8000 align=0x8000 => 0x8000
> > > > vof_claim virt=0xc00000 size=0x18fd62 align=0x0 => 0xc00000
> > > > vof_claimed 0x0..0xc38 size=0xc38
> > > > vof_claimed 0x8000..0x10000 size=0x8000
> > > > vof_claimed 0xc00000..0xd8fd62 size=0x18fd62
> > > > vof_avail 0xc38..0x8000 size=0x73c8
> > > > vof_avail 0x10000..0xc00000 size=0xbf0000
> > > > vof_avail 0xd8fd62..0x20000000 size=0x1f27029e
> > > > via_superio_cfg: unimplemented register 0xf2
> > > > via_superio_cfg: unimplemented register 0xf4
> > > > via_superio_cfg: unimplemented register 0xf6
> > > > via_superio_cfg: unimplemented register 0xf7
[...]
> > OK, I've found that vof.bin needs to be at address 0 then hypercalls work 
> > and it tries to query /chosen/qemu.boot-kernel but I get len = -1 for some 
> > reason. I'm adding the kernel address and size like this:
> >
> >     uint64_t cells[2];
> >
> >     cells[0] = cpu_to_be64(pm->kernel_addr);
> >     cells[1] = cpu_to_be64(pm->kernel_size);
> >     qemu_fdt_setprop(fdt, "/chosen", "qemu,boot-kernel",
> >                      cells, sizeof(cells));
> >
> > which is very much like what spapr does but when vof tries to query it I 
> > get:
>
>
> spapr_vof_reset() also claims the kernel/initrd/VOF memory and allocates the 
> stack,  vof_claim() barfs if there are overlaps.

I've also copied spapr_vof_reset and I don't see an error due to overlap, 
it seems to get past this as seen above. With the latest changes to load 
it to address 0 I see a bit different output:

$ .qemu-system-ppc -M pegasos2 -device ati-vga,romfile="" -cdrom morphos-3.15.iso -kernel 
boot.img -serial stdio -trace enable="vof*" -d unimp,guest_errors,int,in_asm
vof_claim virt=0x0 size=0x55f1 align=0x0 => 0x0
vof_claim virt=0x0 size=0x8000 align=0x8000 => 0x8000
vof_claim virt=0xc00000 size=0x18fd62 align=0x0 => 0xc00000
vof_claimed 0x0..0x55f1 size=0x55f1
vof_claimed 0x8000..0x10000 size=0x8000
vof_claimed 0xc00000..0xd8fd62 size=0x18fd62
vof_avail 0x55f1..0x8000 size=0x2a0f
vof_avail 0x10000..0xc00000 size=0xbf0000
vof_avail 0xd8fd62..0x20000000 size=0x1f27029e

The size of the vof area changed for some reason that I don't understand 
but it starts to run anyway and I get some hypercalls:

Raise exception at 00000150 => 00000008 (01)
hypercall r3=000000000000f005 r4=000000000000fe7c r5=0000000000000001 
r6=0000000000000be8 r7=0000000000000000 r8=000000000000fe78 r9=000000000000fe7c 
r10=0000000000000001 r11=0000000000000000 r12=0000000000000000 nip=00000150
vof_finddevice "/chosen" => ph=0x5

Raise exception at 00000150 => 00000008 (01)
hypercall r3=000000000000f005 r4=000000000000fe6c r5=0000000000000001 
r6=0000000000000005 r7=0000000000000bf0 r8=000000000000fe68 r9=000000000000fe6c 
r10=0000000000000001 r11=000000000000ff60 r12=0000000000000000 nip=00000150
vof_getprop ph=0x5 "qemu,boot-kernel" => len=-1 []

Then it panics here when I think it would jump to the guest code at this 
point if this was successful. I'm probably missing something that VOF 
expects which may cause problems. At the moment I don't have an initrd 
loaded and the stdout path set becuase I did not figure out how the latter 
works. Are those or anything else needed?

> > Raise exception at 00000150 => 00000008 (01)
> > hypercall r3=000000000000f005 r4=000000000000fe6c r5=0000000000000001 
> > r6=0000000000000005 r7=0000000000000bf0 r8=000000000000fe68 
> > r9=000000000000fe6c r10=0000000000000001 r11=000000000000ff60 
> > r12=0000000000000000 nip=00000150
> > vof_getprop ph=0x5 "qemu,boot-kernel" => len=-1 []
> >
> > then it calls exit and the VM stops. Any idea what could be wrong with the 
> > above or what to check?
>
> Memory allocation. Another thing I saw was clang/llvm incorrectly 
> initializing bss start/end for prom (very early boot) so the prim init code 
> in the kernel would memset(0) wrong page and break things. Dunno.

I don't get errors about memory allocation, why do you think that would be 
a problem and where to look for such errors? I'm using your vof.bin, 
haven't recompiled it and using gcc anyway so I don't think I have a 
compiler problem.

I've uploaded my current changes I'm testing with here:

https://osdn.net/projects/qmiga/scm/git/qemu/blobs/pegasos2/hw/ppc/pegasos2.c

and these are the changes

https://osdn.net/projects/qmiga/scm/git/qemu/commits/80c3187758dccffbf167974de98f472ec5c5d03a

in case you can have a look and may spot something obviously wrong. I'm 
running it as above with MorphOS for now as I know that only reads the 
device tree at start up and should not use any other OF services. I'll 
eventually test with Linux too but this seemed simpler for first try and 
should probably work with minimal CI functionality but I hope to find 
that out when it starts.

Regards,
BALATON Zoltan