Re: [PATCH] Add SPR_HSPRG0/1 to 970 hypervisor SPRs

[BALATON Zoltan]

On Sat, 15 Mar 2025, Andrew Randrianasulu wrote:
> On Sat, Mar 15, 2025 at 3:53 PM Andrew Randrianasulu
> <randrianasulu@gmail.com> wrote:
> > ---
> >  target/ppc/cpu_init.c | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
> > index 1780cabfc6..21d3268791 100644
> > --- a/target/ppc/cpu_init.c
> > +++ b/target/ppc/cpu_init.c
> > @@ -5414,6 +5414,16 @@ static void register_970_lpar_sprs(CPUPPCState *env)
> >                   SPR_NOACCESS, SPR_NOACCESS,
> >                   &spr_read_generic, &spr_write_generic,
> >                   0x00000000);
> > +    spr_register_hv(env, SPR_HSPRG0, "HSPRG0",
> > +                 SPR_NOACCESS, SPR_NOACCESS,
> > +                 SPR_NOACCESS, SPR_NOACCESS,
> > +                 &spr_read_generic, &spr_write_generic,
> > +                 0x00000000);
> > +    spr_register_hv(env, SPR_HSPRG1, "HSPRG1",
> > +                 SPR_NOACCESS, SPR_NOACCESS,
> > +                 SPR_NOACCESS, SPR_NOACCESS,
> > +                 &spr_read_generic, &spr_write_generic,
> > +                 0x00000000);
> >  #endif
> >  }
> >
> > --
> > 2.47.1
>
>
> awww, no :(
>
> I tried to log in_asm,guest_errors,unimp,int from QEMU monitor and
> sadly  both with this version or one where I changed spr_register_hv
> to just spr_register log ends with
>
>
> IN:
> 0x00003e14:
> OBJD-T: 7f904ba6eb9f01607fb343a6ebbf016883fe00a0ebde01807ff243a67ff342a6
> OBJD-T: 7fd343a67fd04aa64c000024
>
> ----------------
> IN:
> 0x00003e18:
> OBJD-T: eb9f0160
>
> ----------------
> IN:
> 0x00003e1c:
> OBJD-T: 7fb343a6ebbf016883fe00a0ebde01807ff243a67ff342a67fd343a67fd04aa6
> OBJD-T: 4c000024
>
> ----------------
> IN:
> 0x00003e20:
> OBJD-T: ebbf0168
>
> ----------------
> IN:
> 0x00003e24:
> OBJD-T: 83fe00a0ebde01807ff243a67ff342a67fd343a67fd04aa64c000024

What are these OBJD-T dumps? Shouldn't you see disassembly here? Did you 
check configure output? Maybe it did not find capstone when building? With 
that it would be more readable and more useful output so I suggest to sort 
that out first. At least these still look like valid PPC opcodes.

> invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 0000000000000008
> ----------------
> IN:
> 0x00000000:
> OBJD-T: 555555555555555500000000

This isn't anu more so all this found is it jums to the wrong address 
somewhere after 0x00003e24 (unless there was some previously translated TB 
that could be run from TB cache so won't apprear in -d in_asm). Try to 
figure out what that code does.

> Raise exception at 0000000000000008 => HV_EMU (96) error=21
> Raise exception at 00000000000b21e0 => ISEG (66) error=00
> invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 0000000000000008
> ----------------
> IN:
> 0x00000000:
> OBJD-T: 555555555555555500000000
>
> Raise exception at 0000000000000008 => HV_EMU (96) error=21
> Raise exception at 00000000000b21e0 => ISEG (66) error=00
> invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 0000000000000008
> ----------------
> IN:
> 0x00000000:
> OBJD-T: 555555555555555500000000
>
> Raise exception at 0000000000000008 => HV_EMU (96) error=21
> Raise exception at 00000000000b21e0 => ISEG (66) error=00
> invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 0000000000000008
> ----------------

I don't know what are these exceptions but if these are triggered by 
what's at address 0 then maybe it does not matter as address 0 should not 
be executed so the issue is before where it has jumped to that address.

> Not so simple ....

Usually it isn't but keep exploring and eventually you may find the 
problem after learning a lot about how these work. Even if not fixing it 
might be worth just for the learning experience.

Regards,
BALATON Zoltan