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 0x0000003b0de884ac in __memcmp_sse2 () from /lib64/libc.so.6 #1 0x000000000063f1ad in patch_hypercalls (s=0x139b350) at /work/armbru/qemu/hw/i386/../kvmvapic.c:532 #2 0x000000000063f3fe in vapic_prepare (s=0x139b350) at /work/armbru/qemu/hw/i386/../kvmvapic.c:597 #3 0x000000000063f4ed in vapic_write (opaque=0x139b350, addr=0, data=32, size= 2) at /work/armbru/qemu/hw/i386/../kvmvapic.c:634 #4 0x0000000000677a44 in memory_region_write_accessor (opaque=0x139d670, addr= 0, value=0x7ffff654bbf0, size=2, shift=0, mask=65535) at /work/armbru/qemu/memory.c:329 #5 0x0000000000677b26 in access_with_adjusted_size (addr=0, value= 0x7ffff654bbf0, 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 0x0000000000677f80 in memory_region_iorange_write (iorange=0x139e050, offset=0, width=2, data=32) at /work/armbru/qemu/memory.c:436 #7 0x00000000006709a5 in ioport_writew_thunk (opaque=0x139e050, addr=126, data=32) at /work/armbru/qemu/ioport.c:219 #8 0x0000000000670384 in ioport_write (index=1, address=126, data=32) at /work/armbru/qemu/ioport.c:83 #9 0x0000000000670e32 in cpu_outw (addr=126, val=32) at /work/armbru/qemu/ioport.c:296 #10 0x0000000000674637 in kvm_handle_io (port=126, data=0x7ffff7ffb000, direction=1, size=2, count=1) at /work/armbru/qemu/kvm-all.c:1411 #11 0x0000000000674bc5 in kvm_cpu_exec (env=0x1389b30) at /work/armbru/qemu/kvm-all.c:1556 #12 0x000000000060e0b4 in qemu_kvm_cpu_thread_fn (arg=0x1389b30) at /work/armbru/qemu/cpus.c:757 #13 0x0000003b0ea07d14 in start_thread () from /lib64/libpthread.so.0 #14 0x0000003b0def197d 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=00000000 ECX=00000000 EDX=000fdb64 ESI=00000000 EDI=000fdb64 EBP=00000000 ESP=00006f98 EIP=000e3492 EFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA] SS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] DS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] FS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] GS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA] LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy GDT= 000fcd68 00000037 IDT= 000fdb60 00000000 CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000000 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 Breakpoint on kvm_handle_internal_error() yields backtrace: #0 kvm_handle_internal_error (env=0x1389b30, run=0x7ffff7ffa000) at /work/armbru/qemu/kvm-all.c:1424 #1 0x0000000000674c5a in kvm_cpu_exec (env=0x1389b30) at /work/armbru/qemu/kvm-all.c:1586 #2 0x000000000060e0b4 in qemu_kvm_cpu_thread_fn (arg=0x1389b30) at /work/armbru/qemu/cpus.c:757 #3 0x0000003b0ea07d14 in start_thread () from /lib64/libpthread.so.0 #4 0x0000003b0def197d in clone () from /lib64/libc.so.6 Also seen with 904k, 908k, 964k, 968k, 972k 976k, and a whole lot more. Not reproduced with 1024k+. An easy way to "fix" these is to require 1MiB of RAM :)