qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Trouble with pc_system_firmware_init()


From: Markus Armbruster
Subject: [Qemu-devel] Trouble with pc_system_firmware_init()
Date: Thu, 16 Aug 2012 13:16:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

I noticed a few things I'd like to discuss.

0. pc_fw_add_pflash_drv() lacks error checking, patch coming.

1. Watch this:

    $ qemu-system-x86_64 -nodefaults -S -vnc :0 -bios /dev/null
    Bad ram offset 8000000
    Aborted (core dumped)

   Backtrace:

    #0  0x0000003b0de35925 in raise () from /lib64/libc.so.6
    #1  0x0000003b0de370d8 in abort () from /lib64/libc.so.6
    #2  0x000000000061b606 in qemu_get_ram_ptr (addr=134217728)
        at /work/armbru/qemu/exec.c:2716
    #3  0x000000000067c71a in memory_region_get_ram_ptr (mr=0x13bb358)
        at /work/armbru/qemu/memory.c:1136
    #4  0x0000000000548b6b in pflash_cfi01_register (base=4294967296, qdev=0x0, 
        name=0x803e3e "system.flash", size=0, bs=0x13b9940, sector_len=4096, 
        nb_blocs=0, width=1, id0=0, id1=0, id2=0, id3=0, be=0)
        at /work/armbru/qemu/hw/pflash_cfi01.c:609
    #5  0x0000000000647de3 in pc_system_flash_init (rom_memory=0x13a6400, 
        pflash_drv=0x13aee20) at /work/armbru/qemu/hw/i386/../pc_sysfw.c:134
    #6  0x0000000000648112 in pc_system_firmware_init (rom_memory=0x13a6400)
        at /work/armbru/qemu/hw/i386/../pc_sysfw.c:234
    #7  0x0000000000646607 in pc_memory_init (system_memory=0x138d4f0, 
        kernel_filename=0x0, kernel_cmdline=0x7e6fba "", initrd_filename=0x0, 
        below_4g_mem_size=134217728, above_4g_mem_size=0, rom_memory=0x13a6400, 
        ram_memory=0x7fffffffdbe0) at /work/armbru/qemu/hw/i386/../pc.c:985
    #8  0x000000000064714a in pc_init1 (system_memory=0x138d4f0, system_io=
        0x138d5c0, ram_size=134217728, boot_device=0x7fffffffdf00 "cad", 
        kernel_filename=0x0, kernel_cmdline=0x7e6fba "", initrd_filename=0x0, 
        cpu_model=0x0, pci_enabled=1, kvmclock_enabled=1)
        at /work/armbru/qemu/hw/i386/../pc_piix.c:177
    #9  0x00000000006477ed in pc_init_pci (ram_size=134217728, boot_device=
    ---Type <return> to continue, or q <return> to quit---
        0x7fffffffdf00 "cad", kernel_filename=0x0, kernel_cmdline=0x7e6fba "", 
        initrd_filename=0x0, cpu_model=0x0)
        at /work/armbru/qemu/hw/i386/../pc_piix.c:297
    #10 0x00000000005883d4 in main (argc=7, argv=0x7fffffffe138, envp=
        0x7fffffffe178) at /work/armbru/qemu/vl.c:3571

   Same with an empty regular file instead of /dev/null.

   Shouldn't pflash_cfi01_register() survive funny sizes?  Its code to
   check the size is disabled since commit c8b153d7 "Malta flash
   support.":

    /* XXX: to be fixed */
#if 0
    if (total_len != (8 * 1024 * 1024) && total_len != (16 * 1024 * 1024) &&
        total_len != (32 * 1024 * 1024) && total_len != (64 * 1024 * 1024))
        return NULL;
#endif

   And why do we pass the size both as (sector_len, nb_blocs) and size?
   Since commit cfe5f011 "pflash_cfi01/pflash_cfi02: convert to memory
   API".

   pc_system_flash_init() rejects sizes that aren't a multiple of 4096
   (hardcoded).  Why not just zero-pad up to the next muliple?  If
   that's a bad idea: shouldn't size checking be left to
   pflash_cfi01_register()?

2. If kvm_enabled(), we add a pflash_cfi01 device to hold the BIOS, else
we map a ROM the old-fashioned way.  Doesn't make that guest ABI depend
on the accelerator?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]