From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39098) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UurRB-0006uW-JC for qemu-devel@nongnu.org; Thu, 04 Jul 2013 17:51:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UurRA-0000xO-4t for qemu-devel@nongnu.org; Thu, 04 Jul 2013 17:51:37 -0400 Received: from mout.gmx.net ([212.227.15.15]:59075) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UurR9-0000wJ-Qj for qemu-devel@nongnu.org; Thu, 04 Jul 2013 17:51:36 -0400 Message-ID: <51D5EEAD.9010103@caramail.com> Date: Thu, 04 Jul 2013 23:52:45 +0200 From: Olivier Danet MIME-Version: 1.0 References: <1372385337.2776.153@driftwood> <51CE03D4.1050505@ilande.co.uk> <51CF4394.2030909@caramail.com> In-Reply-To: <51CF4394.2030909@caramail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Openbios upgrade broke sparc32 linux. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rob Landley Cc: Blue Swirl , Mark Cave-Ayland , qemu-devel@nongnu.org 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 >> 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 >> Signed-off-by: Blue Swirl >> >> >> 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]