Re: [Qemu-devel] Openbios upgrade broke sparc32 linux.

[Olivier Danet]

On 29/06/2013 22:29, Olivier Danet wrote:
> On 28/06/2013 23:44, Mark Cave-Ayland wrote:
> > On 28/06/13 03:08, Rob Landley wrote:
> >
> > > Commit 467b34689d27 upgraded the openbios image, and ever since my 
> > > linux
> > > system images hang about the time they try to initialize interrupts.
> > >
> > > http://landley.net/aboriginal/bin/system-image-sparc.tar.bz2
> > >
> > > Extract that and "./run-emulator.sh" in the tarball. Using qemu 1.2.0
> > > for example works fine, you get a shell prompt. Using 1.5.0 hangs.
> > >
> > > Rob
> >
> > Hi Rob,
> >
> > Thanks for the bug report. I did a quick bisect on OpenBIOS and it 
> > points to the following commit:
> >
> > commit 167aafd70f64e74a77787ca5bf9f4dc750b27fc3
> > Author: blueswirl <address@hidden>
> > Date:   Sun Feb 3 16:50:11 2013 +0000
> >
> >     SPARC32: microSPARC-II identification
> >
> >     For the microSPARC-II = Fujitsu MB86904 = Sun STP1012PGA,
> >     PSR.IMPL=0 and PSR.VERS=4.
> >
> >     This CPU model is used as default by QEMU when emulating
> >     a SparcStation-4 or SparcStation-5.
> >
> >     Signed-off-by: Olivier DANET <address@hidden>
> >     Signed-off-by: Blue Swirl <address@hidden>
> >
> >
> > The commit itself is very simple and looks like this: 
> > http://git.qemu.org/?p=openbios.git;a=commitdiff;h=0fe772df8717ef75d91eae8ef221e9966ce2fd7f.
> >
> > My guess would be that Linux is trying to do some slightly different 
> > initialisation based upon identifying the CPU, but I'm not too 
> > familiar with the kernel code myself. Blue/Olivier - can either of 
> > you comment on this?
> >
> >
> > ATB,
> >
> > Mark.
>
> How embarrassing...
>
> - QEMU 1.5.1 can boot Debian Etch (kernel 2.6.18), RedHat 4.2 (kernel 
> 2.0.30), NetBSD 6.1 and OpenBSD 5.3.
>
> - Your image (Linux 3.8) can be started with a TurboSparc CPU : qemu 
> -cpu "Fujitsu MB86907".
>
> - My SparcStation-5 has a 110MHz MicroSPARC-II and the .attributes 
> (aka .properties) fields are identical
> to OpenBIOS values, except for the mask_rev : I have 0x26, OpenBIOS 
> sets 0x23
>
> Before the patch, OpenBIOS had an incoherence between the PSR register 
> content and the BIOS defined values.
> In Linux "arch/sparc/mm/srmmu.c:get_srmmu_type(void)", this correspond 
> to "a TurboSparc emulating Swift".
> (Swift is the MS-2).
>
> TurboSPARC could be the new QEMU default, but, ideally, the MS-II 
> should be preferred
>  as it is compatible with more OSes ( hoping to run NextStep in QEMU 
> one day ...).
>
> Maybe recent Linux kernels are not compatible with the way QEMU 
> emulates the MS-II...
>
> Regards
> Olivier
> [temlib.org]

Hello
I think I have found the problem.

Each SPARC CPU model use different MMU TLB management functions.
For Linux, the callbacks are set in arch/sparc/mm/srmmu.c : 
xxx_flush_tlb_all, xxx_flush_tlb_mm, xxx_flush_tlb_range, 
xxx_flush_tlb_page.
The assembly code used for the MicroSparcII is arch/sparc/mm/swift.S. 
This code accesses the vm_mm member of vm_area_struct 
(include/linux/mm_types.h)

The position of the vm_mm field in the structure was modified recently, 
and the assembly
was not adjusted accordingly.
(https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/include/linux/mm_types.h?id=e4c6bfd2d79d063017ab19a18915f0bc759f32d9)

The bug was introduced in Linux 3.8

Here is a patch for swift, there are also issues in hypersparc.S, 
viking.S, tsunami.S ...:

==========================================================================
diff -up linux_prev/arch/sparc/mm/swift.S linux/arch/sparc/mm/swift.S
--- linux_prev/arch/sparc/mm/swift.S    2013-07-04 23:16:37.785273225 +0200
+++ linux/arch/sparc/mm/swift.S 2013-07-04 23:30:50.445310001 +0200
@@ -105,7 +105,7 @@ swift_flush_cache_mm_out:

        .globl  swift_flush_cache_range
 swift_flush_cache_range:
-       ld      [%o0 + 0x0], %o0                /* XXX vma->vm_mm, GROSS 
XXX */
+       ld      [%o0 + 0x20], %o0               /* XXX vma->vm_mm, GROSS 
XXX */
        sub     %o2, %o1, %o2
        sethi   %hi(4096), %o3
        cmp     %o2, %o3
@@ -116,7 +116,7 @@ swift_flush_cache_range:

        .globl  swift_flush_cache_page
 swift_flush_cache_page:
-       ld      [%o0 + 0x0], %o0                /* XXX vma->vm_mm, GROSS 
XXX */
+       ld      [%o0 + 0x20], %o0               /* XXX vma->vm_mm, GROSS 
XXX */
 70:
        ld      [%o0 + AOFF_mm_context], %g2
        cmp     %g2, -1
@@ -219,7 +219,7 @@ swift_flush_sig_insns:
        .globl  swift_flush_tlb_range
        .globl  swift_flush_tlb_all
 swift_flush_tlb_range:
-       ld      [%o0 + 0x00], %o0       /* XXX vma->vm_mm GROSS XXX */
+       ld      [%o0 + 0x20], %o0       /* XXX vma->vm_mm GROSS XXX */
 swift_flush_tlb_mm:
        ld      [%o0 + AOFF_mm_context], %g2
        cmp     %g2, -1
@@ -233,7 +233,7 @@ swift_flush_tlb_all_out:

        .globl  swift_flush_tlb_page
 swift_flush_tlb_page:
-       ld      [%o0 + 0x00], %o0       /* XXX vma->vm_mm GROSS XXX */
+       ld      [%o0 + 0x20], %o0       /* XXX vma->vm_mm GROSS XXX */
        mov     SRMMU_CTX_REG, %g1
        ld      [%o0 + AOFF_mm_context], %o3
        andn    %o1, (PAGE_SIZE - 1), %o1
==========================================================================

For a cleaner fix, arch/sparc/kernel/asm_offsets.c should be modified.

Cool !
Olivier
[temlib.org]