Re: [Qemu-ppc] standard test image not booting with qemu-system-ppc

[Alexander Graf]

On 03.02.2014, at 22:13, Alexander Graf <address@hidden> wrote:

> 
> On 03.02.2014, at 21:44, Mark Cave-Ayland <address@hidden> wrote:
> 
>> On 03/02/14 20:02, Nitin Srivastava wrote:
>> 
>>> Hi ,
>>> I downloaded the latest qemu source from git and compiled it on my
>>> centos 6.5 machine.
>>> According to the following e-mail from this mailing list I tried the
>>> following
>>> _http://comments.gmane.org/gmane.comp.emulators.qemu/181171_
>>> Test case: download the squeeze standard image from
>>> _http://people.debian.org/~aurel32/qemu/powerpc/_
>>> <http://people.debian.org/%7Eaurel32/qemu/powerpc/>
>>> and run with
>>> qemu-system-ppc -hda debian_squeeze_powerpc_standard.qcow2
>>> but I get following error
>>> VNC server running on `::1:5900'
>>>>> =============================================================
>>>>> OpenBIOS 1.1 [Oct 2 2013 22:57]
>>>>> Configuration device id QEMU version 1 machine id 2
>>>>> CPUs: 1
>>>>> Memory: 128M
>>>>> UUID: 00000000-0000-0000-0000-000000000000
>>>>> CPU type PowerPC,750
>>>>> Not a bootable ELF image
>>> qemu: terminating on signal 2
>>> address@hidden:~:117#
>>> also please note that my qemu-system-ppc is latest, as its built from
>>> source.
>>> address@hidden:~:117#qemu-system-ppc -version
>>> QEMU emulator version 1.7.50, Copyright (c) 2003-2008 Fabrice Bellard
>>> address@hidden:~:118#
>>> Please help.
>>> Regds.
>>> Nitin
>> 
>> Hi Nitin,
>> 
>> Having just updated to git master, I now see this issue too. A quick session 
>> with git bisect shows the culprit is this commit:
>> 
>> 
>> address@hidden:~/src/qemu/git/qemu$ git bisect bad
>> 360e607b88a23d378f6efaa769c76d26f538234d is the first bad commit
>> commit 360e607b88a23d378f6efaa769c76d26f538234d
>> Author: Stefano Stabellini <address@hidden>
>> Date:   Thu Jan 30 12:46:05 2014 +0000
>> 
>>   address_space_translate: do not cross page boundaries
>> 
>> The following commit:
>> 
>> commit 149f54b53b7666a3facd45e86eece60ce7d3b114
>> Author: Paolo Bonzini <address@hidden>
>> Date:   Fri May 24 12:59:37 2013 +0200
>> 
>>   memory: add address_space_translate
>> 
>> breaks Xen support in QEMU, in particular the Xen mapcache. The effect
>> is that one Windows XP installation out of ten would end up with BSOD.
>> 
>> The reason is that after this commit l in address_space_rw can span a
>> page boundary, however qemu_get_ram_ptr still calls xen_map_cache asking
>> to map a single page (if block->offset == 0).
>> 
>> Fix the issue by reverting to the previous behaviour: do not return a
>> length from address_space_translate_internal that can span a page
>> boundary.
>> 
>> Also in address_space_translate do not ignore the length returned by
>> address_space_translate_internal.
>> 
>> This patch should be backported to QEMU 1.6.x.
>> 
>> Signed-off-by: Stefano Stabellini <address@hidden>
>> Signed-off-by: Anthony Perard <address@hidden>
>> Tested-by: Paolo Bonzini <address@hidden>
>> Acked-by: Paolo Bonzini <address@hidden>
>> Cc: address@hidden
>> 
>> 
>> Stefano/Alex, is there any reason why this would break qemu-system-ppc?
> 
> Ugh, sorry Nitin, I should have read the email to the end.
> 
> The image does work for me with -nographic, so I'd assume it's something 
> about the frame buffer map going wrong? We do successfully run the guest:
> 
> address@hidden:/home/agraf/release/qemu> ./ppc-softmmu/qemu-system-ppc -vnc 
> :8 -snapshot -hda /dev/shm/debian_squeeze_powerpc_standard.qcow2 -serial 
> mon:stdio
> 
>>> =============================================================
>>> OpenBIOS 1.1 [Oct 2 2013 22:57]
>>> Configuration device id QEMU version 1 machine id 2
>>> CPUs: 1
>>> Memory: 128M
>>> UUID: 00000000-0000-0000-0000-000000000000
>>> CPU type PowerPC,750
>>> Not a bootable ELF image
> QEMU 1.7.50 monitor - type 'help' for more information
> (qemu) x /i $pc
> 0xfff0c2e0:  b       0xfff0c2ec
> (qemu) x /i $pc
> 0xfff25dd4:  lwz     r0,4(r11)
> (qemu) x /i $pc
> 0xfff1552c:  lhz     r9,0(r4)
> (qemu) x /i $pc
> 0xfff0a868:  lwz     r0,20(r1)
> (qemu) x /i $pc
> 0xfff25d3c:  stw     r31,-4(r11)
> (qemu) x /i $pc
> 0xfff0aeb8:  mr      r31,r3
> (qemu) x /i $pc
> 0xfff0b050:  mr      r31,r3
> (qemu) x /i $pc
> 0xfff0a6cc:  lis     r9,-5
> (qemu) x /i $pc
> 0xc0252a5c:  mr      r3,r31
> (qemu) x /i $pc
> 0xc003e274:  lwz     r9,68(r30)
> 
> so it's really only the VGA output that's broken.

A simple git revert of Stefanos patch makes VGA work again. The diff of "info 
mtree" of a mac99 system with and without his patch is the following:

--- x   2014-02-03 23:57:20.000000000 +0100
+++ y   2014-02-03 23:56:14.000000000 +0100
@@ -30,6 +30,7 @@
 aliases
 pci-mmio
 0000000000000000-00000000ffffffff (prio 0, RW): pci-mmio
+  00000000000a0000-00000000000affff (prio 2, RW): alias vga.chain4 @vga.vram 
0000000000000000-000000000000ffff
   00000000000a0000-00000000000bffff (prio 1, RW): vga-lowmem
   0000000080000000-0000000080ffffff (prio 1, RW): vga.vram
   0000000081000000-0000000081000fff (prio 1, RW): vga.mmio
@@ -77,6 +78,8 @@
   00000000000003d4-00000000000003d5 (prio 0, RW): vga
   00000000000003da-00000000000003da (prio 0, RW): vga
   0000000000000400-00000000000004ff (prio 1, RW): ne2000
+vga.vram
+0000000080000000-0000000080ffffff (prio 1, RW): vga.vram
 escc-bar
 0000000000013000-000000000001303f (prio 0, RW): alias escc-bar @escc 
0000000000000000-000000000000003f
 escc

I'm still not quite sure what did cause the breakage.


Alex