[Qemu-devel] Funny -m arguments can crash

[Qemu-devel] Funny -m arguments can crash

[Markus Armbruster]

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?



$ 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 0x7ffff6efe700 (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.
0x00000033e0835965 in raise () from /lib64/libc.so.6
[...]
(gdb) bt
#0  0x00000033e0835965 in raise () from /lib64/libc.so.6
#1  0x00000033e0837118 in abort () from /lib64/libc.so.6
#2  0x00000033e082e6e2 in __assert_fail_base () from /lib64/libc.so.6
#3  0x00000033e082e792 in __assert_fail () from /lib64/libc.so.6
#4  0x00000000006078fa in register_subpage (section=0x7fffffffd4e0)
    at /work/armbru/qemu/exec.c:2263
#5  0x0000000000607b55 in cpu_register_physical_memory_log (section=
    0x7fffffffd6a0, readonly=false) at /work/armbru/qemu/exec.c:2303
#6  0x0000000000609d1c in core_region_nop (listener=0xac5e60, section=
    0x7fffffffd6a0) at /work/armbru/qemu/exec.c:3183
#7  0x0000000000667a58 in address_space_update_topology_pass (as=0x12fdca0, 
    old_view=..., new_view=..., adding=true) at /work/armbru/qemu/memory.c:693
#8  0x0000000000668045 in address_space_update_topology (as=0x12fdca0)
    at /work/armbru/qemu/memory.c:722
#9  0x0000000000668147 in memory_region_update_topology (mr=0x0)
    at /work/armbru/qemu/memory.c:743
#10 0x0000000000668252 in memory_region_transaction_commit ()
    at /work/armbru/qemu/memory.c:764
#11 0x0000000000636612 in i440fx_update_memory_mappings (d=0x13a9310)
    at /work/armbru/qemu/hw/i386/../piix_pci.c:155
#12 0x0000000000636db6 in i440fx_common_init (device_name=0x7ea470 "i440FX", 
    pi440fx_state=0x7fffffffdb98, piix3_devfn=0x7fffffffdb88, isa_bus=
    0x7fffffffdb90, 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 0x0000000000636ea8 in i440fx_init (pi440fx_state=0x7fffffffdb98, 
    piix3_devfn=0x7fffffffdb88, isa_bus=0x7fffffffdb90, 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 0x000000000063469b in pc_init1 (system_memory=0x1381150, system_io=
    0x1381220, ram_size=838860, boot_device=0x7fffffffdee0 "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 0x0000000000634c0e in pc_init_pci (ram_size=838860, boot_device=
    0x7fffffffdee0 "cad", kernel_filename=0x0, kernel_cmdline=0x7cad82 "", 
    initrd_filename=0x0, cpu_model=0x0)
    at /work/armbru/qemu/hw/i386/../pc_piix.c:297
#16 0x000000000057a89e in main (argc=10, argv=0x7fffffffe118, envp=
    0x7fffffffe170) at /work/armbru/qemu/vl.c:3520
(gdb) up 4
#4  0x00000000006078fa in register_subpage (section=0x7fffffffd4e0)
    at /work/armbru/qemu/exec.c:2263
2263	    assert(existing->mr->subpage || existing->mr == &io_mem_unassigned);
(gdb) p/x *section
$1 = {mr = 0x1399860, address_space = 0x1381150, offset_within_region = 
    0xcccc, size = 0x334, offset_within_address_space = 0xccccc, readonly = 
    0x0}

Re: [Qemu-devel] Funny -m arguments can crash

[Blue Swirl]

On Wed, Jul 25, 2012 at 11:49 AM, Markus Armbruster <armbru@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 0x7ffff6efe700 (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.
> 0x00000033e0835965 in raise () from /lib64/libc.so.6
> [...]
> (gdb) bt
> #0  0x00000033e0835965 in raise () from /lib64/libc.so.6
> #1  0x00000033e0837118 in abort () from /lib64/libc.so.6
> #2  0x00000033e082e6e2 in __assert_fail_base () from /lib64/libc.so.6
> #3  0x00000033e082e792 in __assert_fail () from /lib64/libc.so.6
> #4  0x00000000006078fa in register_subpage (section=0x7fffffffd4e0)
>     at /work/armbru/qemu/exec.c:2263
> #5  0x0000000000607b55 in cpu_register_physical_memory_log (section=
>     0x7fffffffd6a0, readonly=false) at /work/armbru/qemu/exec.c:2303
> #6  0x0000000000609d1c in core_region_nop (listener=0xac5e60, section=
>     0x7fffffffd6a0) at /work/armbru/qemu/exec.c:3183
> #7  0x0000000000667a58 in address_space_update_topology_pass (as=0x12fdca0,
>     old_view=..., new_view=..., adding=true) at /work/armbru/qemu/memory.c:693
> #8  0x0000000000668045 in address_space_update_topology (as=0x12fdca0)
>     at /work/armbru/qemu/memory.c:722
> #9  0x0000000000668147 in memory_region_update_topology (mr=0x0)
>     at /work/armbru/qemu/memory.c:743
> #10 0x0000000000668252 in memory_region_transaction_commit ()
>     at /work/armbru/qemu/memory.c:764
> #11 0x0000000000636612 in i440fx_update_memory_mappings (d=0x13a9310)
>     at /work/armbru/qemu/hw/i386/../piix_pci.c:155
> #12 0x0000000000636db6 in i440fx_common_init (device_name=0x7ea470 "i440FX",
>     pi440fx_state=0x7fffffffdb98, piix3_devfn=0x7fffffffdb88, isa_bus=
>     0x7fffffffdb90, 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 0x0000000000636ea8 in i440fx_init (pi440fx_state=0x7fffffffdb98,
>     piix3_devfn=0x7fffffffdb88, isa_bus=0x7fffffffdb90, 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 0x000000000063469b in pc_init1 (system_memory=0x1381150, system_io=
>     0x1381220, ram_size=838860, boot_device=0x7fffffffdee0 "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 0x0000000000634c0e in pc_init_pci (ram_size=838860, boot_device=
>     0x7fffffffdee0 "cad", kernel_filename=0x0, kernel_cmdline=0x7cad82 "",
>     initrd_filename=0x0, cpu_model=0x0)
>     at /work/armbru/qemu/hw/i386/../pc_piix.c:297
> #16 0x000000000057a89e in main (argc=10, argv=0x7fffffffe118, envp=
>     0x7fffffffe170) at /work/armbru/qemu/vl.c:3520
> (gdb) up 4
> #4  0x00000000006078fa in register_subpage (section=0x7fffffffd4e0)
>     at /work/armbru/qemu/exec.c:2263
> 2263        assert(existing->mr->subpage || existing->mr == &io_mem_unassigned);
> (gdb) p/x *section
> $1 = {mr = 0x1399860, address_space = 0x1381150, offset_within_region =
>     0xcccc, size = 0x334, offset_within_address_space = 0xccccc, readonly =
>     0x0}
>

Re: [Qemu-devel] Funny -m arguments can crash

[Markus Armbruster]

Blue Swirl <blauwirbel@gmail.com> writes:

> On Wed, Jul 25, 2012 at 11:49 AM, Markus Armbruster <armbru@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

[Blue Swirl]

On Sat, Jul 28, 2012 at 6:41 AM, Markus Armbruster <armbru@redhat.com> wrote:
> Blue Swirl <blauwirbel@gmail.com> writes:
>
>> On Wed, Jul 25, 2012 at 11:49 AM, Markus Armbruster <armbru@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

[Markus Armbruster]

Blue Swirl <blauwirbel@gmail.com> writes:

> On Sat, Jul 28, 2012 at 6:41 AM, Markus Armbruster <armbru@redhat.com> wrote:
>> Blue Swirl <blauwirbel@gmail.com> writes:
>>
>>> On Wed, Jul 25, 2012 at 11:49 AM, Markus Armbruster
>>> <armbru@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

[Blue Swirl]

On Mon, Jul 30, 2012 at 12:56 PM, Markus Armbruster <armbru@redhat.com> wrote:
> Blue Swirl <blauwirbel@gmail.com> writes:
>
>> On Sat, Jul 28, 2012 at 6:41 AM, Markus Armbruster <armbru@redhat.com> wrote:
>>> Blue Swirl <blauwirbel@gmail.com> writes:
>>>
>>>> On Wed, Jul 25, 2012 at 11:49 AM, Markus Armbruster
>>>> <armbru@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

[Markus Armbruster]

Blue Swirl <blauwirbel@gmail.com> writes:

> On Mon, Jul 30, 2012 at 12:56 PM, Markus Armbruster <armbru@redhat.com> wrote:
>> Blue Swirl <blauwirbel@gmail.com> writes:
>>
>>> On Sat, Jul 28, 2012 at 6:41 AM, Markus Armbruster <armbru@redhat.com> wrote:
>>>> Blue Swirl <blauwirbel@gmail.com> writes:
>>>>
>>>>> On Wed, Jul 25, 2012 at 11:49 AM, Markus Armbruster
>>>>> <armbru@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

[Peter Maydell]

On 8 August 2012 10:04, Markus Armbruster <armbru@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

[Avi Kivity]

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

[Markus Armbruster]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 8 August 2012 10:04, Markus Armbruster <armbru@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

[Markus Armbruster]

Avi Kivity <avi@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

[Avi Kivity]

On 08/13/2012 04:41 PM, Markus Armbruster wrote:
> Avi Kivity <avi@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

[Gleb Natapov]

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 <avi@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

[Avi Kivity]

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

[Gleb Natapov]

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

[Anthony Liguori]

Markus Armbruster <armbru@redhat.com> writes:

> Avi Kivity <avi@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

[Markus Armbruster]

Anthony Liguori <anthony@codemonkey.ws> writes:

> Markus Armbruster <armbru@redhat.com> writes:
>
>> Avi Kivity <avi@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

[Blue Swirl]

On Mon, Aug 13, 2012 at 2:10 PM, Gleb Natapov <gleb@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

[Markus Armbruster]

Anthony Liguori <anthony@codemonkey.ws> writes:

> Markus Armbruster <armbru@redhat.com> writes:
>
>> Avi Kivity <avi@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 :)

Re: [Qemu-devel] Funny -m arguments can crash

[Avi Kivity]

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  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=
> 
> 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=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
> 

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=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.

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

[Jan Kiszka]

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  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=
>>
>> 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

[Avi Kivity]

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  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=
>>>
>>> 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

[Jan Kiszka]

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  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=
>>>>
>>>> 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

[Markus Armbruster]

Avi Kivity <avi@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=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
>> 
>
> 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=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.
>
> Same EIP in the dump with those?

Offenders within 1s in range 868k..1028k step 4:

900
EIP=000e3492 EFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
904
EIP=000e3492 EFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
908
EIP=000e3492 EFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
916
EIP=000e570e EFL=00000012 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=0
964
EIP=000f2b76 EFL=00000012 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=0
968
EIP=000f2b76 EFL=00000012 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=0
972
EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
976
EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
980
EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
984
EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
988
EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
992
EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
996
EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
1000
EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
1004
EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
1008
EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
1012
EIP=000fe69f EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
1016
EIP=000fe69f EFL=00000083 [--S---C] CPL=0 II=0 A20=1 SMM=0 HLT=0
1020
EIP=0000f000 EFL=00000046 [---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

[Avi Kivity]

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

[Jan Kiszka]

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

[Avi Kivity]

On 08/14/2012 02:12 PM, Markus Armbruster wrote:
> Avi Kivity <avi@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=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
>>> 
>>
>> 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=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.
>>
>> Same EIP in the dump with those?
> 
> Offenders within 1s in range 868k..1028k step 4:
> 
> 900
> EIP=000e3492 EFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
> 904
> EIP=000e3492 EFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
> 908
> EIP=000e3492 EFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
> 916
> EIP=000e570e EFL=00000012 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=0
> 964
> EIP=000f2b76 EFL=00000012 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=0
> 968
> EIP=000f2b76 EFL=00000012 [----A--] CPL=0 II=0 A20=1 SMM=0 HLT=0
> 972
> EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
> 976
> EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
> 980
> EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
> 984
> EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
> 988
> EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
> 992
> EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
> 996
> EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
> 1000
> EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
> 1004
> EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
> 1008
> EIP=000fc6db EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
> 1012
> EIP=000fe69f EFL=00000087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
> 1016
> EIP=000fe69f EFL=00000083 [--S---C] CPL=0 II=0 A20=1 SMM=0 HLT=0
> 1020
> EIP=0000f000 EFL=00000046 [---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

[Avi Kivity]

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

[Kevin O'Connor]

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