Re: [Qemu-ppc] [OpenBIOS] Running client with MMU off

[Alexander Graf]

On 26.06.14 01:36, BALATON Zoltan wrote:
> On Wed, 25 Jun 2014, Alexander Graf wrote:
> > On 25.06.14 12:40, BALATON Zoltan wrote:
> > > On Wed, 25 Jun 2014, BALATON Zoltan wrote:
> > > > ppc_store_sdr1: 0fe00000
> > > > helper_store_sr: reg=0 20000400 00000000
> > > [...]
> > > > helper_store_sr: reg=0 00000000 20000400
> > > > Raise exception at 0041cd00 => 00000003 (40000000)
> > > >
> > > > ^^^ This exception should not happen. It is trying to handle it but 
> > > > the handlers are not working yet and gets in an infinite loop. It 
> > > > boots if MMU is disabled while this part runs but MorphOS does not 
> > > > disable it yet and according to my oftest results they are enabled 
> > > > on Apple too. How does it work on real hardware and why does it 
> > > > fail on QEMU? (Note the the value of sr0 is identical to the one 
> > > > set by OpenBIOS and SDR1 is unchanged so translations via the page 
> > > > table should still work, shouldn't it?)
> > >
> > > I was mistaken about the values being the same as it is zeroing sr0. 
> > > So can this explain why translation via the page table fails after 
> > > this and why an ISI is generated? Why are the sr registers set up 
> > > with the values above by OpenBIOS? Could they be 0 instead?
> >
> > SR registers are used to translate EAs to VAs. If you set them all to 
> > 0 they would end up getting the same VSID.
>
> OK but why is SEGR_BASE defined as 0x0400 in arch/ppc/qemu/ofmem.c? 

I guess to make it easier to debug vs empty SR registers and to make 
sure it doesn't collide with a guest that sets SR registers to 0 
temporarily?

What does real Apple firmware use for their VSIDs?

> If I change this to 0 I get closer and it survives zeroing the sr 
> registers but it cannot survive zeroing SDR1 and crashes after that 
> happens:
>
> IN:
> 0x0041cde0: lwz     r0,60(r3)
>
> htab_base 000000000fe00000 htab_mask 000000000000ffff hash 
> 000000000000041c
> 0 htab=000000000fe00000/000000000000ffff vsid=0 ptem=1 
> hash=000000000000041c
>
> 0x0041cde4: sync
>
> htab_base 000000000fe00000 htab_mask 000000000000ffff hash 
> 000000000000041c
> 0 htab=000000000fe00000/000000000000ffff vsid=0 ptem=1 
> hash=000000000000041c
>
> 0x0041cde8: mtsr    15,r0
>
> htab_base 000000000fe00000 htab_mask 000000000000ffff hash 
> 000000000000041c
> 0 htab=000000000fe00000/000000000000ffff vsid=0 ptem=1 
> hash=000000000000041c
>
> 0x0041cdec: isync
>
> htab_base 000000000fe00000 htab_mask 000000000000ffff hash 
> 000000000000041c
> 0 htab=000000000fe00000/000000000000ffff vsid=0 ptem=1 
> hash=000000000000041c
>
> htab_base 000000000fe00000 htab_mask 000000000000ffff hash 
> 0000000000000697
> 0 htab=000000000fe00000/000000000000ffff vsid=0 ptem=1 
> hash=0000000000000697
> found PTE at offset 0000a5e0
> PTE access granted !
>
> helper_store_sr: reg=15 00000000 2000000f
>
> htab_base 000000000fe00000 htab_mask 000000000000ffff hash 
> 000000000000041c
> 0 htab=000000000fe00000/000000000000ffff vsid=0 ptem=1 
> hash=000000000000041c
> found PTE at offset 00000728
> PTE access granted !
>
> IN:
> 0x0041cdf0: sync
>
> htab_base 000000000fe00000 htab_mask 000000000000ffff hash 
> 000000000000041c
> 0 htab=000000000fe00000/000000000000ffff vsid=0 ptem=1 
> hash=000000000000041c
>
> 0x0041cdf4: mtsdr1  r6
>
> htab_base 000000000fe00000 htab_mask 000000000000ffff hash 
> 000000000000041c
> 0 htab=000000000fe00000/000000000000ffff vsid=0 ptem=1 
> hash=000000000000041c
>
> 0x0041cdf8: isync
>
> htab_base 000000000fe00000 htab_mask 000000000000ffff hash 
> 000000000000041c
> 0 htab=000000000fe00000/000000000000ffff vsid=0 ptem=1 
> hash=000000000000041c
>
> ppc_store_sdr1: 00000000
>
> htab_base 0000000000000000 htab_mask 000000000000ffff hash 
> 000000000000041c
> 0 htab=0000000000000000/000000000000ffff vsid=0 ptem=1 
> hash=000000000000041c
> 1 htab=0000000000000000/000000000000ffff vsid=0 api=1 
> hash=fffffffffffffbe3
> Raise exception at 0041cdfc => 00000003 (40000000)
> IN:
> 0x00000400:  mtsprg  2,r2
>
> What comes after this is loading some values from the stack then 
> disabling MMU bits in MSR (then putting the values loaded into BAT 
> regs). If I could get these run without getting an ISI inbetween it 
> would boot:
>
>   41ce0c:       82 84 00 14     lwz     r20,20(r4)
>   41ce10:       82 a4 00 10     lwz     r21,16(r4)
>   41ce14:       82 c4 00 1c     lwz     r22,28(r4)
>   41ce18:       82 e4 00 18     lwz     r23,24(r4)
>   41ce1c:       83 05 00 04     lwz     r24,4(r5)
>   41ce20:       83 25 00 00     lwz     r25,0(r5)
>   41ce24:       83 45 00 0c     lwz     r26,12(r5)
>   41ce28:       83 65 00 08     lwz     r27,8(r5)
>   41ce2c:       83 85 00 14     lwz     r28,20(r5)
>   41ce30:       83 a5 00 10     lwz     r29,16(r5)
>   41ce34:       83 c5 00 1c     lwz     r30,28(r5)
>   41ce38:       83 e5 00 18     lwz     r31,24(r5)
>   41ce3c:       7c 00 04 ac     sync
>   41ce40:       7c 00 00 a6     mfmsr   r0
>   41ce44:       70 00 ff cf     andi.   r0,r0,65487
>   41ce48:       7c 00 04 ac     sync
>   41ce4c:       7c 00 01 24     mtmsr   r0
>   41ce50:       4c 00 01 2c     isync
>
> Why are we getting ISIs on QEMU and why can this work on real hardware 
> without crashing?

We are getting ISIs because the HTAB is now 0 bytes long, so it doesn't 
contain any entries. Maybe it works on real hardware by accident because 
the translations are still in the TLB?

I think with MorphOS you're best off detecting that you are running 
MorphOS somehow (checksum over loaded files, specific client interface 
calls only it does) and set MSR.DR=0 and MSR.IR=0.


Alex