Re: [Qemu-devel] Funny -m arguments can crash
On Mon, Aug 13, 2012 at 04:56:53PM +0300, Avi Kivity wrote: IMO we need to fix CMOS reporting. (technically we shouldn't touch CMOS NVRAM at all; seabios should discover memory size via fwcfg and program it itself. But it's pointless to change it now) It would be nice to pass all values via fw_cfg instead of cmos. Using the cmos to pass valus is cumbersome. If there is some desire to specify memory to a finer granularity than 1MiB (and frankly I'm struggling to understand the desire for that), then lets pass it via fw_cfg instead of cmos. -Kevin
Re: [Qemu-devel] Funny -m arguments can crash
Anthony Liguori anth...@codemonkey.ws writes: Markus Armbruster arm...@redhat.com writes: Avi Kivity a...@redhat.com writes: On 08/08/2012 12:04 PM, Markus Armbruster wrote: Yes please, maybe with a notice to the user. Next problem: minimum RAM size. For instance, -M pc -m X, where X 32KiB dies qemu: fatal: Trying to execute code outside RAM or ROM at [...] Aborted (core dumped) with TCG, and KVM internal error. Suberror: 1 with KVM. Should a minimum RAM size be enforced? Board-specific? It's really a BIOS bug causing a limitation of both kvm and tcg to be hit. The BIOS should recognize it doesn't have sufficient memory and hang gracefully (if you can picture that). It just assumes some low memory is available and tries to execute it with the results you got. SeaBIOS indeed assumes it got at least 1MiB of RAM. It doesn't bother to check CMOS for a smaller RAM size. However, that bug / feature is currently masked by a QEMU bug: we screw up CMOS contents when there's less than 1 MiB of RAM. pc_cmos_init(): int val, nb, i; [...] /* memory size */ val = 640; /* base memory in K */ rtc_set_memory(s, 0x15, val); rtc_set_memory(s, 0x16, val 8); val = (ram_size / 1024) - 1024; if (val 65535) val = 65535; rtc_set_memory(s, 0x17, val); rtc_set_memory(s, 0x18, val 8); If ram_size 1MiB, val goes negative. Oops. For instance, with -m 500k, we happily promise 640KiB base memory (CMOS addr 0x15..16), almost 64MiB extended memory (0x17..18 and 0x30..31), yet no memory above 16MiB (0x34..35). An easy way to fix this is to require 1MiB of RAM :) But if you like, I'll put sane values in CMOS instead. That'll expose the SeaBIOS bug. Anthony, you're the PC maintainer, got a preference? SeaBIOS thread: http://comments.gmane.org/gmane.comp.bios.coreboot.seabios/4341 I'd prefer fixing the CMOS values over limiting to 1MB of RAM. Having a 1MB limit is purely theoritical--not practical. There's no good reason for anyone to ask for 1MB unless they know what they're doing. If it's truly a mistake, then asking for 2MB is just as much of a mistake because no real guest will run with 2MB of memory anyway (you can't even load a kernel). So if we're just going for theoritical correctness, we ought to do it the Right Way which is fixing the CMOS values and putting the check in SeaBIOS. Next error: $ gdb --args qemu-system-x86_64 -nodefaults --enable-kvm -vnc :0 -monitor stdio -m 640k [...] Program received signal SIGSEGV, Segmentation fault. [...] (gdb) bt #0 0x003b0de884ac in __memcmp_sse2 () from /lib64/libc.so.6 #1 0x0063f1ad in patch_hypercalls (s=0x139b350) at /work/armbru/qemu/hw/i386/../kvmvapic.c:532 #2 0x0063f3fe in vapic_prepare (s=0x139b350) at /work/armbru/qemu/hw/i386/../kvmvapic.c:597 #3 0x0063f4ed in vapic_write (opaque=0x139b350, addr=0, data=32, size= 2) at /work/armbru/qemu/hw/i386/../kvmvapic.c:634 #4 0x00677a44 in memory_region_write_accessor (opaque=0x139d670, addr= 0, value=0x7654bbf0, size=2, shift=0, mask=65535) at /work/armbru/qemu/memory.c:329 #5 0x00677b26 in access_with_adjusted_size (addr=0, value= 0x7654bbf0, size=2, access_size_min=1, access_size_max=4, access= 0x6779d0 memory_region_write_accessor, opaque=0x139d670) at /work/armbru/qemu/memory.c:359 #6 0x00677f80 in memory_region_iorange_write (iorange=0x139e050, offset=0, width=2, data=32) at /work/armbru/qemu/memory.c:436 #7 0x006709a5 in ioport_writew_thunk (opaque=0x139e050, addr=126, data=32) at /work/armbru/qemu/ioport.c:219 #8 0x00670384 in ioport_write (index=1, address=126, data=32) at /work/armbru/qemu/ioport.c:83 #9 0x00670e32 in cpu_outw (addr=126, val=32) at /work/armbru/qemu/ioport.c:296 #10 0x00674637 in kvm_handle_io (port=126, data=0x77ffb000, direction=1, size=2, count=1) at /work/armbru/qemu/kvm-all.c:1411 #11 0x00674bc5 in kvm_cpu_exec (env=0x1389b30) at /work/armbru/qemu/kvm-all.c:1556 #12 0x0060e0b4 in qemu_kvm_cpu_thread_fn (arg=0x1389b30) at /work/armbru/qemu/cpus.c:757 #13 0x003b0ea07d14 in start_thread () from /lib64/libpthread.so.0 #14 0x003b0def197d in clone () from /lib64/libc.so.6 Happens when -m argument is a multiple of 4k in [648k..768k]. Only with --enable-kvm. With and without my CMOS fix applied. And another one: $ qemu-system-x86_64 -nodefaults --enable-kvm -vnc :0 -monitor stdio -m 900k QEMU 1.1.50 monitor - type 'help' for more information (qemu) KVM internal error. Suberror: 1 emulation failure EAX=000fdb78 EBX= ECX= EDX=000fdb64 ESI= EDI=000fdb64 EBP= ESP=6f98 EIP=000e3492 EFL=0006
Re: [Qemu-devel] Funny -m arguments can crash
On 08/14/2012 11:44 AM, Markus Armbruster wrote: Next error: $ gdb --args qemu-system-x86_64 -nodefaults --enable-kvm -vnc :0 -monitor stdio -m 640k [...] Program received signal SIGSEGV, Segmentation fault. [...] (gdb) bt #0 0x003b0de884ac in __memcmp_sse2 () from /lib64/libc.so.6 #1 0x0063f1ad in patch_hypercalls (s=0x139b350) at /work/armbru/qemu/hw/i386/../kvmvapic.c:532 #2 0x0063f3fe in vapic_prepare (s=0x139b350) at /work/armbru/qemu/hw/i386/../kvmvapic.c:597 #3 0x0063f4ed in vapic_write (opaque=0x139b350, addr=0, data=32, size= 2) at /work/armbru/qemu/hw/i386/../kvmvapic.c:634 #4 0x00677a44 in memory_region_write_accessor (opaque=0x139d670, addr= Happens when -m argument is a multiple of 4k in [648k..768k]. Only with --enable-kvm. With and without my CMOS fix applied. kvmvapic requires RAM to be present underneath the ROM. We could fix up kvmvapic to allocate a 4k region and insert it as an overlay, but it's sufficient IMO to require sub-1M users to disable it. It won't be of any use to the anyway as Windows XP requires more than 1MB. And another one: $ qemu-system-x86_64 -nodefaults --enable-kvm -vnc :0 -monitor stdio -m 900k QEMU 1.1.50 monitor - type 'help' for more information (qemu) KVM internal error. Suberror: 1 emulation failure EAX=000fdb78 EBX= ECX= EDX=000fdb64 ESI= EDI=000fdb64 EBP= ESP=6f98 EIP=000e3492 EFL=0006 [-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 000fcd68 0037 IDT= 000fdb60 CR0=0011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=00 00 b8 26 00 00 00 eb 95 83 c8 ff 83 c4 4c 5b 5e 5f 5d c3 57 56 53 89 d6 39 c2 72 06 89 c7 f3 a4 eb 1b 8d 51 ff 01 d0 01 d6 89 cf 31 d2 eb 08 8a 1c q Not sure what's the problem. 57 is a push reg instruction which we ought to emulate fine. 900k is 0xe1000, just below eip, but we ought to execute just fine from unshadowed ROM. Breakpoint on kvm_handle_internal_error() yields backtrace: #0 kvm_handle_internal_error (env=0x1389b30, run=0x77ffa000) at /work/armbru/qemu/kvm-all.c:1424 #1 0x00674c5a in kvm_cpu_exec (env=0x1389b30) at /work/armbru/qemu/kvm-all.c:1586 #2 0x0060e0b4 in qemu_kvm_cpu_thread_fn (arg=0x1389b30) at /work/armbru/qemu/cpus.c:757 #3 0x003b0ea07d14 in start_thread () from /lib64/libpthread.so.0 #4 0x003b0def197d in clone () from /lib64/libc.so.6 Also seen with 904k, 908k, 964k, 968k, 972k 976k, and a whole lot more. Same EIP in the dump with those? Not reproduced with 1024k+. An easy way to fix these is to require 1MiB of RAM :) Or disabling kvm. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Funny -m arguments can crash
On 2012-08-14 12:20, Avi Kivity wrote: On 08/14/2012 11:44 AM, Markus Armbruster wrote: Next error: $ gdb --args qemu-system-x86_64 -nodefaults --enable-kvm -vnc :0 -monitor stdio -m 640k [...] Program received signal SIGSEGV, Segmentation fault. [...] (gdb) bt #0 0x003b0de884ac in __memcmp_sse2 () from /lib64/libc.so.6 #1 0x0063f1ad in patch_hypercalls (s=0x139b350) at /work/armbru/qemu/hw/i386/../kvmvapic.c:532 #2 0x0063f3fe in vapic_prepare (s=0x139b350) at /work/armbru/qemu/hw/i386/../kvmvapic.c:597 #3 0x0063f4ed in vapic_write (opaque=0x139b350, addr=0, data=32, size= 2) at /work/armbru/qemu/hw/i386/../kvmvapic.c:634 #4 0x00677a44 in memory_region_write_accessor (opaque=0x139d670, addr= Happens when -m argument is a multiple of 4k in [648k..768k]. Only with --enable-kvm. With and without my CMOS fix applied. kvmvapic requires RAM to be present underneath the ROM. We could fix up kvmvapic to allocate a 4k region and insert it as an overlay, but it's sufficient IMO to require sub-1M users to disable it. It won't be of any use to the anyway as Windows XP requires more than 1MB. We can also easily automatically disable it when there is insufficient (1MB) memory. Will post a patch. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
Re: [Qemu-devel] Funny -m arguments can crash
On 08/14/2012 01:44 PM, Jan Kiszka wrote: On 2012-08-14 12:20, Avi Kivity wrote: On 08/14/2012 11:44 AM, Markus Armbruster wrote: Next error: $ gdb --args qemu-system-x86_64 -nodefaults --enable-kvm -vnc :0 -monitor stdio -m 640k [...] Program received signal SIGSEGV, Segmentation fault. [...] (gdb) bt #0 0x003b0de884ac in __memcmp_sse2 () from /lib64/libc.so.6 #1 0x0063f1ad in patch_hypercalls (s=0x139b350) at /work/armbru/qemu/hw/i386/../kvmvapic.c:532 #2 0x0063f3fe in vapic_prepare (s=0x139b350) at /work/armbru/qemu/hw/i386/../kvmvapic.c:597 #3 0x0063f4ed in vapic_write (opaque=0x139b350, addr=0, data=32, size= 2) at /work/armbru/qemu/hw/i386/../kvmvapic.c:634 #4 0x00677a44 in memory_region_write_accessor (opaque=0x139d670, addr= Happens when -m argument is a multiple of 4k in [648k..768k]. Only with --enable-kvm. With and without my CMOS fix applied. kvmvapic requires RAM to be present underneath the ROM. We could fix up kvmvapic to allocate a 4k region and insert it as an overlay, but it's sufficient IMO to require sub-1M users to disable it. It won't be of any use to the anyway as Windows XP requires more than 1MB. We can also easily automatically disable it when there is insufficient (1MB) memory. Will post a patch. Would be nicer if it auto-disables itself, but don't know if the option ROM has access to the memory size. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Funny -m arguments can crash
On 2012-08-14 12:51, Avi Kivity wrote: On 08/14/2012 01:44 PM, Jan Kiszka wrote: On 2012-08-14 12:20, Avi Kivity wrote: On 08/14/2012 11:44 AM, Markus Armbruster wrote: Next error: $ gdb --args qemu-system-x86_64 -nodefaults --enable-kvm -vnc :0 -monitor stdio -m 640k [...] Program received signal SIGSEGV, Segmentation fault. [...] (gdb) bt #0 0x003b0de884ac in __memcmp_sse2 () from /lib64/libc.so.6 #1 0x0063f1ad in patch_hypercalls (s=0x139b350) at /work/armbru/qemu/hw/i386/../kvmvapic.c:532 #2 0x0063f3fe in vapic_prepare (s=0x139b350) at /work/armbru/qemu/hw/i386/../kvmvapic.c:597 #3 0x0063f4ed in vapic_write (opaque=0x139b350, addr=0, data=32, size= 2) at /work/armbru/qemu/hw/i386/../kvmvapic.c:634 #4 0x00677a44 in memory_region_write_accessor (opaque=0x139d670, addr= Happens when -m argument is a multiple of 4k in [648k..768k]. Only with --enable-kvm. With and without my CMOS fix applied. kvmvapic requires RAM to be present underneath the ROM. We could fix up kvmvapic to allocate a 4k region and insert it as an overlay, but it's sufficient IMO to require sub-1M users to disable it. It won't be of any use to the anyway as Windows XP requires more than 1MB. We can also easily automatically disable it when there is insufficient (1MB) memory. Will post a patch. Would be nicer if it auto-disables itself, but don't know if the option ROM has access to the memory size. There is that global ram_size, also used by vmport. Not really nice but no precedent. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
Re: [Qemu-devel] Funny -m arguments can crash
Avi Kivity a...@redhat.com writes: On 08/14/2012 11:44 AM, Markus Armbruster wrote: [...] And another one: $ qemu-system-x86_64 -nodefaults --enable-kvm -vnc :0 -monitor stdio -m 900k QEMU 1.1.50 monitor - type 'help' for more information (qemu) KVM internal error. Suberror: 1 emulation failure EAX=000fdb78 EBX= ECX= EDX=000fdb64 ESI= EDI=000fdb64 EBP= ESP=6f98 EIP=000e3492 EFL=0006 [-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 000fcd68 0037 IDT= 000fdb60 CR0=0011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=00 00 b8 26 00 00 00 eb 95 83 c8 ff 83 c4 4c 5b 5e 5f 5d c3 57 56 53 89 d6 39 c2 72 06 89 c7 f3 a4 eb 1b 8d 51 ff 01 d0 01 d6 89 cf 31 d2 eb 08 8a 1c q Not sure what's the problem. 57 is a push reg instruction which we ought to emulate fine. 900k is 0xe1000, just below eip, but we ought to execute just fine from unshadowed ROM. Breakpoint on kvm_handle_internal_error() yields backtrace: #0 kvm_handle_internal_error (env=0x1389b30, run=0x77ffa000) at /work/armbru/qemu/kvm-all.c:1424 #1 0x00674c5a in kvm_cpu_exec (env=0x1389b30) at /work/armbru/qemu/kvm-all.c:1586 #2 0x0060e0b4 in qemu_kvm_cpu_thread_fn (arg=0x1389b30) at /work/armbru/qemu/cpus.c:757 #3 0x003b0ea07d14 in start_thread () from /lib64/libpthread.so.0 #4 0x003b0def197d in clone () from /lib64/libc.so.6 Also seen with 904k, 908k, 964k, 968k, 972k 976k, and a whole lot more. Same EIP in the dump with those? Offenders within 1s in range 868k..1028k step 4: 900 EIP=000e3492 EFL=0006 [-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 904 EIP=000e3492 EFL=0006 [-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 908 EIP=000e3492 EFL=0006 [-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 916 EIP=000e570e EFL=0012 [A--] CPL=0 II=0 A20=1 SMM=0 HLT=0 964 EIP=000f2b76 EFL=0012 [A--] CPL=0 II=0 A20=1 SMM=0 HLT=0 968 EIP=000f2b76 EFL=0012 [A--] CPL=0 II=0 A20=1 SMM=0 HLT=0 972 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 976 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 980 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 984 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 988 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 992 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 996 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 1000 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 1004 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 1008 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 1012 EIP=000fe69f EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 1016 EIP=000fe69f EFL=0083 [--S---C] CPL=0 II=0 A20=1 SMM=0 HLT=0 1020 EIP=f000 EFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 Not reproduced with 1024k+. An easy way to fix these is to require 1MiB of RAM :) Or disabling kvm.
Re: [Qemu-devel] Funny -m arguments can crash
On 08/14/2012 02:01 PM, Jan Kiszka wrote: We can also easily automatically disable it when there is insufficient (1MB) memory. Will post a patch. Would be nicer if it auto-disables itself, but don't know if the option ROM has access to the memory size. There is that global ram_size, also used by vmport. Not really nice but no precedent. I meant do the detection in the guest. But don't respin the patch, it doesn't really matter and host-side works just as well. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Funny -m arguments can crash
On 08/14/2012 02:12 PM, Markus Armbruster wrote: Avi Kivity a...@redhat.com writes: On 08/14/2012 11:44 AM, Markus Armbruster wrote: [...] And another one: $ qemu-system-x86_64 -nodefaults --enable-kvm -vnc :0 -monitor stdio -m 900k QEMU 1.1.50 monitor - type 'help' for more information (qemu) KVM internal error. Suberror: 1 emulation failure EAX=000fdb78 EBX= ECX= EDX=000fdb64 ESI= EDI=000fdb64 EBP= ESP=6f98 EIP=000e3492 EFL=0006 [-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 000fcd68 0037 IDT= 000fdb60 CR0=0011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=00 00 b8 26 00 00 00 eb 95 83 c8 ff 83 c4 4c 5b 5e 5f 5d c3 57 56 53 89 d6 39 c2 72 06 89 c7 f3 a4 eb 1b 8d 51 ff 01 d0 01 d6 89 cf 31 d2 eb 08 8a 1c q Not sure what's the problem. 57 is a push reg instruction which we ought to emulate fine. 900k is 0xe1000, just below eip, but we ought to execute just fine from unshadowed ROM. Breakpoint on kvm_handle_internal_error() yields backtrace: #0 kvm_handle_internal_error (env=0x1389b30, run=0x77ffa000) at /work/armbru/qemu/kvm-all.c:1424 #1 0x00674c5a in kvm_cpu_exec (env=0x1389b30) at /work/armbru/qemu/kvm-all.c:1586 #2 0x0060e0b4 in qemu_kvm_cpu_thread_fn (arg=0x1389b30) at /work/armbru/qemu/cpus.c:757 #3 0x003b0ea07d14 in start_thread () from /lib64/libpthread.so.0 #4 0x003b0def197d in clone () from /lib64/libc.so.6 Also seen with 904k, 908k, 964k, 968k, 972k 976k, and a whole lot more. Same EIP in the dump with those? Offenders within 1s in range 868k..1028k step 4: 900 EIP=000e3492 EFL=0006 [-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 904 EIP=000e3492 EFL=0006 [-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 908 EIP=000e3492 EFL=0006 [-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 916 EIP=000e570e EFL=0012 [A--] CPL=0 II=0 A20=1 SMM=0 HLT=0 964 EIP=000f2b76 EFL=0012 [A--] CPL=0 II=0 A20=1 SMM=0 HLT=0 968 EIP=000f2b76 EFL=0012 [A--] CPL=0 II=0 A20=1 SMM=0 HLT=0 972 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 976 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 980 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 984 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 988 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 992 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 996 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 1000 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 1004 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 1008 EIP=000fc6db EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 1012 EIP=000fe69f EFL=0087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 1016 EIP=000fe69f EFL=0083 [--S---C] CPL=0 II=0 A20=1 SMM=0 HLT=0 1020 EIP=f000 EFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 Seems like crash eip always end of memory. It's the new flash firmware: it's set up as rom_device, and we can't execute from that (yet). There's a patchset to allow that, but it's not merged yet. If you set pc-sysfw.rom_only, it should work. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Funny -m arguments can crash
On 2012-08-14 15:16, Avi Kivity wrote: On 08/14/2012 02:01 PM, Jan Kiszka wrote: We can also easily automatically disable it when there is insufficient (1MB) memory. Will post a patch. Would be nicer if it auto-disables itself, but don't know if the option ROM has access to the memory size. There is that global ram_size, also used by vmport. Not really nice but no precedent. I meant do the detection in the guest. But don't respin the patch, it doesn't really matter and host-side works just as well. We must not allow the guest to decide over this. Unless I'm misinterpreting something, a malicious guest could still trigger this patching (in non-existent RAM) and crash the host. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
Re: [Qemu-devel] Funny -m arguments can crash
On 08/14/2012 04:25 PM, Jan Kiszka wrote: On 2012-08-14 15:16, Avi Kivity wrote: On 08/14/2012 02:01 PM, Jan Kiszka wrote: We can also easily automatically disable it when there is insufficient (1MB) memory. Will post a patch. Would be nicer if it auto-disables itself, but don't know if the option ROM has access to the memory size. There is that global ram_size, also used by vmport. Not really nice but no precedent. I meant do the detection in the guest. But don't respin the patch, it doesn't really matter and host-side works just as well. We must not allow the guest to decide over this. Unless I'm misinterpreting something, a malicious guest could still trigger this patching (in non-existent RAM) and crash the host. Right. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Funny -m arguments can crash
Avi Kivity a...@redhat.com writes: On 08/08/2012 12:04 PM, Markus Armbruster wrote: Yes please, maybe with a notice to the user. Next problem: minimum RAM size. For instance, -M pc -m X, where X 32KiB dies qemu: fatal: Trying to execute code outside RAM or ROM at [...] Aborted (core dumped) with TCG, and KVM internal error. Suberror: 1 with KVM. Should a minimum RAM size be enforced? Board-specific? It's really a BIOS bug causing a limitation of both kvm and tcg to be hit. The BIOS should recognize it doesn't have sufficient memory and hang gracefully (if you can picture that). It just assumes some low memory is available and tries to execute it with the results you got. SeaBIOS indeed assumes it got at least 1MiB of RAM. It doesn't bother to check CMOS for a smaller RAM size. However, that bug / feature is currently masked by a QEMU bug: we screw up CMOS contents when there's less than 1 MiB of RAM. pc_cmos_init(): int val, nb, i; [...] /* memory size */ val = 640; /* base memory in K */ rtc_set_memory(s, 0x15, val); rtc_set_memory(s, 0x16, val 8); val = (ram_size / 1024) - 1024; if (val 65535) val = 65535; rtc_set_memory(s, 0x17, val); rtc_set_memory(s, 0x18, val 8); If ram_size 1MiB, val goes negative. Oops. For instance, with -m 500k, we happily promise 640KiB base memory (CMOS addr 0x15..16), almost 64MiB extended memory (0x17..18 and 0x30..31), yet no memory above 16MiB (0x34..35). An easy way to fix this is to require 1MiB of RAM :) But if you like, I'll put sane values in CMOS instead. That'll expose the SeaBIOS bug. Anthony, you're the PC maintainer, got a preference? SeaBIOS thread: http://comments.gmane.org/gmane.comp.bios.coreboot.seabios/4341
Re: [Qemu-devel] Funny -m arguments can crash
On 08/13/2012 04:41 PM, Markus Armbruster wrote: Avi Kivity a...@redhat.com writes: On 08/08/2012 12:04 PM, Markus Armbruster wrote: Yes please, maybe with a notice to the user. Next problem: minimum RAM size. For instance, -M pc -m X, where X 32KiB dies qemu: fatal: Trying to execute code outside RAM or ROM at [...] Aborted (core dumped) with TCG, and KVM internal error. Suberror: 1 with KVM. Should a minimum RAM size be enforced? Board-specific? It's really a BIOS bug causing a limitation of both kvm and tcg to be hit. The BIOS should recognize it doesn't have sufficient memory and hang gracefully (if you can picture that). It just assumes some low memory is available and tries to execute it with the results you got. SeaBIOS indeed assumes it got at least 1MiB of RAM. It doesn't bother to check CMOS for a smaller RAM size. However, that bug / feature is currently masked by a QEMU bug: we screw up CMOS contents when there's less than 1 MiB of RAM. pc_cmos_init(): int val, nb, i; [...] /* memory size */ val = 640; /* base memory in K */ rtc_set_memory(s, 0x15, val); rtc_set_memory(s, 0x16, val 8); val = (ram_size / 1024) - 1024; if (val 65535) val = 65535; rtc_set_memory(s, 0x17, val); rtc_set_memory(s, 0x18, val 8); If ram_size 1MiB, val goes negative. Oops. For instance, with -m 500k, we happily promise 640KiB base memory (CMOS addr 0x15..16), almost 64MiB extended memory (0x17..18 and 0x30..31), yet no memory above 16MiB (0x34..35). An easy way to fix this is to require 1MiB of RAM :) But if you like, I'll put sane values in CMOS instead. That'll expose the SeaBIOS bug. IMO we need to fix CMOS reporting. (technically we shouldn't touch CMOS NVRAM at all; seabios should discover memory size via fwcfg and program it itself. But it's pointless to change it now) -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Funny -m arguments can crash
On Mon, Aug 13, 2012 at 04:56:53PM +0300, Avi Kivity wrote: On 08/13/2012 04:41 PM, Markus Armbruster wrote: Avi Kivity a...@redhat.com writes: On 08/08/2012 12:04 PM, Markus Armbruster wrote: Yes please, maybe with a notice to the user. Next problem: minimum RAM size. For instance, -M pc -m X, where X 32KiB dies qemu: fatal: Trying to execute code outside RAM or ROM at [...] Aborted (core dumped) with TCG, and KVM internal error. Suberror: 1 with KVM. Should a minimum RAM size be enforced? Board-specific? It's really a BIOS bug causing a limitation of both kvm and tcg to be hit. The BIOS should recognize it doesn't have sufficient memory and hang gracefully (if you can picture that). It just assumes some low memory is available and tries to execute it with the results you got. SeaBIOS indeed assumes it got at least 1MiB of RAM. It doesn't bother to check CMOS for a smaller RAM size. However, that bug / feature is currently masked by a QEMU bug: we screw up CMOS contents when there's less than 1 MiB of RAM. pc_cmos_init(): int val, nb, i; [...] /* memory size */ val = 640; /* base memory in K */ rtc_set_memory(s, 0x15, val); rtc_set_memory(s, 0x16, val 8); val = (ram_size / 1024) - 1024; if (val 65535) val = 65535; rtc_set_memory(s, 0x17, val); rtc_set_memory(s, 0x18, val 8); If ram_size 1MiB, val goes negative. Oops. For instance, with -m 500k, we happily promise 640KiB base memory (CMOS addr 0x15..16), almost 64MiB extended memory (0x17..18 and 0x30..31), yet no memory above 16MiB (0x34..35). An easy way to fix this is to require 1MiB of RAM :) But if you like, I'll put sane values in CMOS instead. That'll expose the SeaBIOS bug. IMO we need to fix CMOS reporting. (technically we shouldn't touch CMOS NVRAM at all; seabios should discover memory size via fwcfg and program it itself. But it's pointless to change it now) Chipset we emulate does not support all those crazy memory values you can give to -m. -- Gleb.
Re: [Qemu-devel] Funny -m arguments can crash
On 08/13/2012 05:02 PM, Gleb Natapov wrote: IMO we need to fix CMOS reporting. (technically we shouldn't touch CMOS NVRAM at all; seabios should discover memory size via fwcfg and program it itself. But it's pointless to change it now) Chipset we emulate does not support all those crazy memory values you can give to -m. Our chipset is a 440fx enhanced with fwcfg and other goodies, not a plain 440fx. But it's true it probably doesn't support 82.66642kB RAM. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Funny -m arguments can crash
On Mon, Aug 13, 2012 at 05:04:30PM +0300, Avi Kivity wrote: On 08/13/2012 05:02 PM, Gleb Natapov wrote: IMO we need to fix CMOS reporting. (technically we shouldn't touch CMOS NVRAM at all; seabios should discover memory size via fwcfg and program it itself. But it's pointless to change it now) Chipset we emulate does not support all those crazy memory values you can give to -m. Our chipset is a 440fx enhanced with fwcfg and other goodies, not a plain 440fx. It has registers to program DIMM slots configs. fwcfg does not enhanced it in any way. And you cannot program more than 4G memory there may be even less. So what do you mean by program it itself? Program CMOS itself? (What for? QEMU does not care). Or program 440fx DIMM config? But it's true it probably doesn't support 82.66642kB RAM. It does not support much less exotic 4G. -- Gleb.
Re: [Qemu-devel] Funny -m arguments can crash
Markus Armbruster arm...@redhat.com writes: Avi Kivity a...@redhat.com writes: On 08/08/2012 12:04 PM, Markus Armbruster wrote: Yes please, maybe with a notice to the user. Next problem: minimum RAM size. For instance, -M pc -m X, where X 32KiB dies qemu: fatal: Trying to execute code outside RAM or ROM at [...] Aborted (core dumped) with TCG, and KVM internal error. Suberror: 1 with KVM. Should a minimum RAM size be enforced? Board-specific? It's really a BIOS bug causing a limitation of both kvm and tcg to be hit. The BIOS should recognize it doesn't have sufficient memory and hang gracefully (if you can picture that). It just assumes some low memory is available and tries to execute it with the results you got. SeaBIOS indeed assumes it got at least 1MiB of RAM. It doesn't bother to check CMOS for a smaller RAM size. However, that bug / feature is currently masked by a QEMU bug: we screw up CMOS contents when there's less than 1 MiB of RAM. pc_cmos_init(): int val, nb, i; [...] /* memory size */ val = 640; /* base memory in K */ rtc_set_memory(s, 0x15, val); rtc_set_memory(s, 0x16, val 8); val = (ram_size / 1024) - 1024; if (val 65535) val = 65535; rtc_set_memory(s, 0x17, val); rtc_set_memory(s, 0x18, val 8); If ram_size 1MiB, val goes negative. Oops. For instance, with -m 500k, we happily promise 640KiB base memory (CMOS addr 0x15..16), almost 64MiB extended memory (0x17..18 and 0x30..31), yet no memory above 16MiB (0x34..35). An easy way to fix this is to require 1MiB of RAM :) But if you like, I'll put sane values in CMOS instead. That'll expose the SeaBIOS bug. Anthony, you're the PC maintainer, got a preference? SeaBIOS thread: http://comments.gmane.org/gmane.comp.bios.coreboot.seabios/4341 I'd prefer fixing the CMOS values over limiting to 1MB of RAM. Having a 1MB limit is purely theoritical--not practical. There's no good reason for anyone to ask for 1MB unless they know what they're doing. If it's truly a mistake, then asking for 2MB is just as much of a mistake because no real guest will run with 2MB of memory anyway (you can't even load a kernel). So if we're just going for theoritical correctness, we ought to do it the Right Way which is fixing the CMOS values and putting the check in SeaBIOS. Regards, Anthony Liguori
Re: [Qemu-devel] Funny -m arguments can crash
Anthony Liguori anth...@codemonkey.ws writes: Markus Armbruster arm...@redhat.com writes: Avi Kivity a...@redhat.com writes: On 08/08/2012 12:04 PM, Markus Armbruster wrote: Yes please, maybe with a notice to the user. Next problem: minimum RAM size. For instance, -M pc -m X, where X 32KiB dies qemu: fatal: Trying to execute code outside RAM or ROM at [...] Aborted (core dumped) with TCG, and KVM internal error. Suberror: 1 with KVM. Should a minimum RAM size be enforced? Board-specific? It's really a BIOS bug causing a limitation of both kvm and tcg to be hit. The BIOS should recognize it doesn't have sufficient memory and hang gracefully (if you can picture that). It just assumes some low memory is available and tries to execute it with the results you got. SeaBIOS indeed assumes it got at least 1MiB of RAM. It doesn't bother to check CMOS for a smaller RAM size. However, that bug / feature is currently masked by a QEMU bug: we screw up CMOS contents when there's less than 1 MiB of RAM. pc_cmos_init(): int val, nb, i; [...] /* memory size */ val = 640; /* base memory in K */ rtc_set_memory(s, 0x15, val); rtc_set_memory(s, 0x16, val 8); val = (ram_size / 1024) - 1024; if (val 65535) val = 65535; rtc_set_memory(s, 0x17, val); rtc_set_memory(s, 0x18, val 8); If ram_size 1MiB, val goes negative. Oops. For instance, with -m 500k, we happily promise 640KiB base memory (CMOS addr 0x15..16), almost 64MiB extended memory (0x17..18 and 0x30..31), yet no memory above 16MiB (0x34..35). An easy way to fix this is to require 1MiB of RAM :) But if you like, I'll put sane values in CMOS instead. That'll expose the SeaBIOS bug. Anthony, you're the PC maintainer, got a preference? SeaBIOS thread: http://comments.gmane.org/gmane.comp.bios.coreboot.seabios/4341 I'd prefer fixing the CMOS values over limiting to 1MB of RAM. Having a 1MB limit is purely theoritical--not practical. There's no good reason for anyone to ask for 1MB unless they know what they're doing. If it's truly a mistake, then asking for 2MB is just as much of a mistake because no real guest will run with 2MB of memory anyway (you can't even load a kernel). So if we're just going for theoritical correctness, we ought to do it the Right Way which is fixing the CMOS values and putting the check in SeaBIOS. Okay, I'll cook up a patch fixing pc_cmos_init().
Re: [Qemu-devel] Funny -m arguments can crash
On Mon, Aug 13, 2012 at 2:10 PM, Gleb Natapov g...@redhat.com wrote: On Mon, Aug 13, 2012 at 05:04:30PM +0300, Avi Kivity wrote: On 08/13/2012 05:02 PM, Gleb Natapov wrote: IMO we need to fix CMOS reporting. (technically we shouldn't touch CMOS NVRAM at all; seabios should discover memory size via fwcfg and program it itself. But it's pointless to change it now) Chipset we emulate does not support all those crazy memory values you can give to -m. Our chipset is a 440fx enhanced with fwcfg and other goodies, not a plain 440fx. It has registers to program DIMM slots configs. fwcfg does not enhanced it in any way. And you cannot program more than 4G memory there may be even less. So what do you mean by program it itself? Program CMOS itself? (What for? QEMU does not care). Or program 440fx DIMM config? An idealistic emulator would not have an fw_cfg but it would let BIOS discover everything, exactly like a real BIOS would do. It would also support using BIOS ROM images from real 440fx machine. This approach, taken to its extreme, would eventually lead to an cycle accurate emulator, it would emulate various chip erratas and probably become a very slow monster. However, the approach which we have taken in QEMU is that performance is more important than uselessly exact emulation and the OSes don't care what is the exact interface between BIOS and HW. Thus we can take a few PV shortcuts. Modeling the RAM as linear area with any integer amount of MB has taken us pretty far, but modeling the DIMM slots can still be interesting because it gives better emulation without performance loss. Modeling what happens if CAS latency programming is off limits would not be interesting for QEMU. But it's true it probably doesn't support 82.66642kB RAM. It does not support much less exotic 4G. -- Gleb.
Re: [Qemu-devel] Funny -m arguments can crash
Blue Swirl blauwir...@gmail.com writes: On Mon, Jul 30, 2012 at 12:56 PM, Markus Armbruster arm...@redhat.com wrote: Blue Swirl blauwir...@gmail.com writes: On Sat, Jul 28, 2012 at 6:41 AM, Markus Armbruster arm...@redhat.com wrote: Blue Swirl blauwir...@gmail.com writes: On Wed, Jul 25, 2012 at 11:49 AM, Markus Armbruster arm...@redhat.com wrote: Asking for funny memory sizes sometimes crashes for me. For instance -m 0.8 or the equivalent -m 838860b. -m 0.7 appears to work. Should we round memory sizes? How? Where? We had a discussion about this recently: http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg02800.html I missed that, thanks! Unfortunately, the thread petered out without a conclusion. What now? There's no patch to do the check in vl.c for 8k. Lacking the patch, we don't know exactly what is the charge level of megaphone batteries: like Schrödinger's cat, they may be dead or fully charged. What would you like me to do? Round argument of -m up to next multiple of 8KiB? Yes please, maybe with a notice to the user. Next problem: minimum RAM size. For instance, -M pc -m X, where X 32KiB dies qemu: fatal: Trying to execute code outside RAM or ROM at [...] Aborted (core dumped) with TCG, and KVM internal error. Suberror: 1 with KVM. Should a minimum RAM size be enforced? Board-specific? I'm inclined to declare this one a feature...
Re: [Qemu-devel] Funny -m arguments can crash
On 8 August 2012 10:04, Markus Armbruster arm...@redhat.com wrote: Next problem: minimum RAM size. For instance, -M pc -m X, where X 32KiB dies qemu: fatal: Trying to execute code outside RAM or ROM at [...] Aborted (core dumped) with TCG, and KVM internal error. Suberror: 1 with KVM. Should a minimum RAM size be enforced? Board-specific? Good luck. Last time I tried to add RAM size checks it got shot down in review... (http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg02907.html) -- PMM
Re: [Qemu-devel] Funny -m arguments can crash
On 08/08/2012 12:04 PM, Markus Armbruster wrote: Yes please, maybe with a notice to the user. Next problem: minimum RAM size. For instance, -M pc -m X, where X 32KiB dies qemu: fatal: Trying to execute code outside RAM or ROM at [...] Aborted (core dumped) with TCG, and KVM internal error. Suberror: 1 with KVM. Should a minimum RAM size be enforced? Board-specific? It's really a BIOS bug causing a limitation of both kvm and tcg to be hit. The BIOS should recognize it doesn't have sufficient memory and hang gracefully (if you can picture that). It just assumes some low memory is available and tries to execute it with the results you got. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Funny -m arguments can crash
Peter Maydell peter.mayd...@linaro.org writes: On 8 August 2012 10:04, Markus Armbruster arm...@redhat.com wrote: Next problem: minimum RAM size. For instance, -M pc -m X, where X 32KiB dies qemu: fatal: Trying to execute code outside RAM or ROM at [...] Aborted (core dumped) with TCG, and KVM internal error. Suberror: 1 with KVM. Should a minimum RAM size be enforced? Board-specific? Good luck. Last time I tried to add RAM size checks it got shot down in review... (http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg02907.html) I think I want to stay out of that swamp; thanks for the warning.
Re: [Qemu-devel] Funny -m arguments can crash
Blue Swirl blauwir...@gmail.com writes: On Sat, Jul 28, 2012 at 6:41 AM, Markus Armbruster arm...@redhat.com wrote: Blue Swirl blauwir...@gmail.com writes: On Wed, Jul 25, 2012 at 11:49 AM, Markus Armbruster arm...@redhat.com wrote: Asking for funny memory sizes sometimes crashes for me. For instance -m 0.8 or the equivalent -m 838860b. -m 0.7 appears to work. Should we round memory sizes? How? Where? We had a discussion about this recently: http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg02800.html I missed that, thanks! Unfortunately, the thread petered out without a conclusion. What now? There's no patch to do the check in vl.c for 8k. Lacking the patch, we don't know exactly what is the charge level of megaphone batteries: like Schrödinger's cat, they may be dead or fully charged. What would you like me to do? Round argument of -m up to next multiple of 8KiB?
Re: [Qemu-devel] Funny -m arguments can crash
On Mon, Jul 30, 2012 at 12:56 PM, Markus Armbruster arm...@redhat.com wrote: Blue Swirl blauwir...@gmail.com writes: On Sat, Jul 28, 2012 at 6:41 AM, Markus Armbruster arm...@redhat.com wrote: Blue Swirl blauwir...@gmail.com writes: On Wed, Jul 25, 2012 at 11:49 AM, Markus Armbruster arm...@redhat.com wrote: Asking for funny memory sizes sometimes crashes for me. For instance -m 0.8 or the equivalent -m 838860b. -m 0.7 appears to work. Should we round memory sizes? How? Where? We had a discussion about this recently: http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg02800.html I missed that, thanks! Unfortunately, the thread petered out without a conclusion. What now? There's no patch to do the check in vl.c for 8k. Lacking the patch, we don't know exactly what is the charge level of megaphone batteries: like Schrödinger's cat, they may be dead or fully charged. What would you like me to do? Round argument of -m up to next multiple of 8KiB? Yes please, maybe with a notice to the user.
Re: [Qemu-devel] Funny -m arguments can crash
Blue Swirl blauwir...@gmail.com writes: On Wed, Jul 25, 2012 at 11:49 AM, Markus Armbruster arm...@redhat.com wrote: Asking for funny memory sizes sometimes crashes for me. For instance -m 0.8 or the equivalent -m 838860b. -m 0.7 appears to work. Should we round memory sizes? How? Where? We had a discussion about this recently: http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg02800.html I missed that, thanks! Unfortunately, the thread petered out without a conclusion. What now?
Re: [Qemu-devel] Funny -m arguments can crash
On Sat, Jul 28, 2012 at 6:41 AM, Markus Armbruster arm...@redhat.com wrote: Blue Swirl blauwir...@gmail.com writes: On Wed, Jul 25, 2012 at 11:49 AM, Markus Armbruster arm...@redhat.com wrote: Asking for funny memory sizes sometimes crashes for me. For instance -m 0.8 or the equivalent -m 838860b. -m 0.7 appears to work. Should we round memory sizes? How? Where? We had a discussion about this recently: http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg02800.html I missed that, thanks! Unfortunately, the thread petered out without a conclusion. What now? There's no patch to do the check in vl.c for 8k. Lacking the patch, we don't know exactly what is the charge level of megaphone batteries: like Schrödinger's cat, they may be dead or fully charged.
Re: [Qemu-devel] Funny -m arguments can crash
On Wed, Jul 25, 2012 at 11:49 AM, Markus Armbruster arm...@redhat.com wrote:
Asking for funny memory sizes sometimes crashes for me. For instance
-m 0.8 or the equivalent -m 838860b. -m 0.7 appears to work.
Should we round memory sizes? How? Where?
We had a discussion about this recently:
http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg02800.html
$ gdb --args qemu-system-x86_64 -nodefaults --enable-kvm -S -vnc :0 -monitor
stdio -m 0.8
[...]
(gdb) r
Starting program: /home/armbru/bin/upstream-qemu -nodefaults --enable-kvm -S
-vnc :0 -monitor stdio -m 0.8
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib64/libthread_db.so.1.
[New Thread 0x76efe700 (LWP 29525)]
upstream-qemu: /work/armbru/qemu/exec.c:2263: register_subpage: Assertion
`existing-mr-subpage || existing-mr == io_mem_unassigned' failed.
Program received signal SIGABRT, Aborted.
0x0033e0835965 in raise () from /lib64/libc.so.6
[...]
(gdb) bt
#0 0x0033e0835965 in raise () from /lib64/libc.so.6
#1 0x0033e0837118 in abort () from /lib64/libc.so.6
#2 0x0033e082e6e2 in __assert_fail_base () from /lib64/libc.so.6
#3 0x0033e082e792 in __assert_fail () from /lib64/libc.so.6
#4 0x006078fa in register_subpage (section=0x7fffd4e0)
at /work/armbru/qemu/exec.c:2263
#5 0x00607b55 in cpu_register_physical_memory_log (section=
0x7fffd6a0, readonly=false) at /work/armbru/qemu/exec.c:2303
#6 0x00609d1c in core_region_nop (listener=0xac5e60, section=
0x7fffd6a0) at /work/armbru/qemu/exec.c:3183
#7 0x00667a58 in address_space_update_topology_pass (as=0x12fdca0,
old_view=..., new_view=..., adding=true) at /work/armbru/qemu/memory.c:693
#8 0x00668045 in address_space_update_topology (as=0x12fdca0)
at /work/armbru/qemu/memory.c:722
#9 0x00668147 in memory_region_update_topology (mr=0x0)
at /work/armbru/qemu/memory.c:743
#10 0x00668252 in memory_region_transaction_commit ()
at /work/armbru/qemu/memory.c:764
#11 0x00636612 in i440fx_update_memory_mappings (d=0x13a9310)
at /work/armbru/qemu/hw/i386/../piix_pci.c:155
#12 0x00636db6 in i440fx_common_init (device_name=0x7ea470 i440FX,
pi440fx_state=0x7fffdb98, piix3_devfn=0x7fffdb88, isa_bus=
0x7fffdb90, pic=0x13a49c0, address_space_mem=0x1381150,
address_space_io=0x1381220, ram_size=0, pci_hole_start=838860,
pci_hole_size=4294128436, pci_hole64_start=4294967296, pci_hole64_size=
4611686018427387904, pci_address_space=0x13a4200, ram_memory=0x13a42b0)
at /work/armbru/qemu/hw/i386/../piix_pci.c:330
#13 0x00636ea8 in i440fx_init (pi440fx_state=0x7fffdb98,
piix3_devfn=0x7fffdb88, isa_bus=0x7fffdb90, pic=0x13a49c0,
address_space_mem=0x1381150, address_space_io=0x1381220, ram_size=838860,
pci_hole_start=838860, pci_hole_size=4294128436, pci_hole64_start=
4294967296, pci_hole64_size=4611686018427387904, pci_memory=0x13a4200,
ram_memory=0x13a42b0) at /work/armbru/qemu/hw/i386/../piix_pci.c:349
#14 0x0063469b in pc_init1 (system_memory=0x1381150, system_io=
0x1381220, ram_size=838860, boot_device=0x7fffdee0 cad,
kernel_filename=0x0, kernel_cmdline=0x7cad82 , initrd_filename=0x0,
cpu_model=0x0, pci_enabled=1, kvmclock_enabled=1)
at /work/armbru/qemu/hw/i386/../pc_piix.c:193
#15 0x00634c0e in pc_init_pci (ram_size=838860, boot_device=
0x7fffdee0 cad, kernel_filename=0x0, kernel_cmdline=0x7cad82 ,
initrd_filename=0x0, cpu_model=0x0)
at /work/armbru/qemu/hw/i386/../pc_piix.c:297
#16 0x0057a89e in main (argc=10, argv=0x7fffe118, envp=
0x7fffe170) at /work/armbru/qemu/vl.c:3520
(gdb) up 4
#4 0x006078fa in register_subpage (section=0x7fffd4e0)
at /work/armbru/qemu/exec.c:2263
2263assert(existing-mr-subpage || existing-mr ==
io_mem_unassigned);
(gdb) p/x *section
$1 = {mr = 0x1399860, address_space = 0x1381150, offset_within_region =
0x, size = 0x334, offset_within_address_space = 0xc, readonly =
0x0}
