2012-02-22 11:18:51 +04:00
|
|
|
/*
|
|
|
|
* QEMU PC System Firmware
|
|
|
|
*
|
|
|
|
* Copyright (c) 2003-2004 Fabrice Bellard
|
|
|
|
* Copyright (c) 2011-2012 Intel Corporation
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
2014-10-07 15:59:13 +04:00
|
|
|
#include "sysemu/block-backend.h"
|
2013-02-04 14:37:52 +04:00
|
|
|
#include "qemu/error-report.h"
|
2013-02-04 18:40:22 +04:00
|
|
|
#include "hw/sysbus.h"
|
|
|
|
#include "hw/hw.h"
|
2013-02-05 20:06:20 +04:00
|
|
|
#include "hw/i386/pc.h"
|
2012-02-22 11:18:53 +04:00
|
|
|
#include "hw/boards.h"
|
2013-02-04 18:40:22 +04:00
|
|
|
#include "hw/loader.h"
|
2012-12-17 21:20:04 +04:00
|
|
|
#include "sysemu/sysemu.h"
|
2013-02-05 20:06:20 +04:00
|
|
|
#include "hw/block/flash.h"
|
2012-12-17 21:20:04 +04:00
|
|
|
#include "sysemu/kvm.h"
|
2012-02-22 11:18:51 +04:00
|
|
|
|
|
|
|
#define BIOS_FILENAME "bios.bin"
|
|
|
|
|
2012-02-22 11:18:52 +04:00
|
|
|
typedef struct PcSysFwDevice {
|
|
|
|
SysBusDevice busdev;
|
2013-05-29 12:27:24 +04:00
|
|
|
uint8_t isapc_ram_fw;
|
2012-02-22 11:18:52 +04:00
|
|
|
} PcSysFwDevice;
|
|
|
|
|
2012-02-22 11:18:53 +04:00
|
|
|
static void pc_isa_bios_init(MemoryRegion *rom_memory,
|
|
|
|
MemoryRegion *flash_mem,
|
|
|
|
int ram_size)
|
|
|
|
{
|
|
|
|
int isa_bios_size;
|
|
|
|
MemoryRegion *isa_bios;
|
|
|
|
uint64_t flash_size;
|
|
|
|
void *flash_ptr, *isa_bios_ptr;
|
|
|
|
|
|
|
|
flash_size = memory_region_size(flash_mem);
|
|
|
|
|
|
|
|
/* map the last 128KB of the BIOS in ISA space */
|
2013-07-31 17:11:12 +04:00
|
|
|
isa_bios_size = MIN(flash_size, 128 * 1024);
|
2012-02-22 11:18:53 +04:00
|
|
|
isa_bios = g_malloc(sizeof(*isa_bios));
|
2014-09-09 09:27:55 +04:00
|
|
|
memory_region_init_ram(isa_bios, NULL, "isa-bios", isa_bios_size,
|
Fix bad error handling after memory_region_init_ram()
Symptom:
$ qemu-system-x86_64 -m 10000000
Unexpected error in ram_block_add() at /work/armbru/qemu/exec.c:1456:
upstream-qemu: cannot set up guest memory 'pc.ram': Cannot allocate memory
Aborted (core dumped)
Root cause: commit ef701d7 screwed up handling of out-of-memory
conditions. Before the commit, we report the error and exit(1), in
one place, ram_block_add(). The commit lifts the error handling up
the call chain some, to three places. Fine. Except it uses
&error_abort in these places, changing the behavior from exit(1) to
abort(), and thus undoing the work of commit 3922825 "exec: Don't
abort when we can't allocate guest memory".
The three places are:
* memory_region_init_ram()
Commit 4994653 (right after commit ef701d7) lifted the error
handling further, through memory_region_init_ram(), multiplying the
incorrect use of &error_abort. Later on, imitation of existing
(bad) code may have created more.
* memory_region_init_ram_ptr()
The &error_abort is still there.
* memory_region_init_rom_device()
Doesn't need fixing, because commit 33e0eb5 (soon after commit
ef701d7) lifted the error handling further, and in the process
changed it from &error_abort to passing it up the call chain.
Correct, because the callers are realize() methods.
Fix the error handling after memory_region_init_ram() with a
Coccinelle semantic patch:
@r@
expression mr, owner, name, size, err;
position p;
@@
memory_region_init_ram(mr, owner, name, size,
(
- &error_abort
+ &error_fatal
|
err@p
)
);
@script:python@
p << r.p;
@@
print "%s:%s:%s" % (p[0].file, p[0].line, p[0].column)
When the last argument is &error_abort, it gets replaced by
&error_fatal. This is the fix.
If the last argument is anything else, its position is reported. This
lets us check the fix is complete. Four positions get reported:
* ram_backend_memory_alloc()
Error is passed up the call chain, ultimately through
user_creatable_complete(). As far as I can tell, it's callers all
handle the error sanely.
* fsl_imx25_realize(), fsl_imx31_realize(), dp8393x_realize()
DeviceClass.realize() methods, errors handled sanely further up the
call chain.
We're good. Test case again behaves:
$ qemu-system-x86_64 -m 10000000
qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory
[Exit 1 ]
The next commits will repair the rest of commit ef701d7's damage.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1441983105-26376-3-git-send-email-armbru@redhat.com>
Reviewed-by: Peter Crosthwaite <crosthwaite.peter@gmail.com>
2015-09-11 17:51:43 +03:00
|
|
|
&error_fatal);
|
2012-02-22 11:18:53 +04:00
|
|
|
vmstate_register_ram_global(isa_bios);
|
|
|
|
memory_region_add_subregion_overlap(rom_memory,
|
|
|
|
0x100000 - isa_bios_size,
|
|
|
|
isa_bios,
|
|
|
|
1);
|
|
|
|
|
|
|
|
/* copy ISA rom image from top of flash memory */
|
|
|
|
flash_ptr = memory_region_get_ram_ptr(flash_mem);
|
|
|
|
isa_bios_ptr = memory_region_get_ram_ptr(isa_bios);
|
|
|
|
memcpy(isa_bios_ptr,
|
|
|
|
((uint8_t*)flash_ptr) + (flash_size - isa_bios_size),
|
|
|
|
isa_bios_size);
|
|
|
|
|
|
|
|
memory_region_set_readonly(isa_bios, true);
|
|
|
|
}
|
|
|
|
|
hw/i386/pc_sysfw: support two flash drives
This patch allows the user to usefully specify
-drive file=img_1,if=pflash,format=raw,readonly \
-drive file=img_2,if=pflash,format=raw
on the command line. The flash images will be mapped under 4G in their
reverse unit order -- that is, with their base addresses progressing
downwards, in increasing unit order.
(The unit number increases with command line order if not explicitly
specified.)
This accommodates the following use case: suppose that OVMF is split in
two parts, a writeable host file for non-volatile variable storage, and a
read-only part for bootstrap and decompressible executable code.
The binary code part would be read-only, centrally managed on the host
system, and passed in as unit 0. The variable store would be writeable,
VM-specific, and passed in as unit 1.
00000000ffe00000-00000000ffe1ffff (prio 0, R-): system.flash1
00000000ffe20000-00000000ffffffff (prio 0, R-): system.flash0
(If the guest tries to write to the flash range that is backed by the
read-only drive, pflash_update() is never called; various flash
programming/erase errors are returned to the guest instead. See the
callers of pflash_update(), and the initialization of "pfl->ro", in
"hw/block/pflash_cfi01.c".)
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-11-28 03:52:52 +04:00
|
|
|
#define FLASH_MAP_UNIT_MAX 2
|
|
|
|
|
|
|
|
/* We don't have a theoretically justifiable exact lower bound on the base
|
|
|
|
* address of any flash mapping. In practice, the IO-APIC MMIO range is
|
|
|
|
* [0xFEE00000..0xFEE01000[ -- see IO_APIC_DEFAULT_ADDRESS --, leaving free
|
|
|
|
* only 18MB-4KB below 4G. For now, restrict the cumulative mapping to 8MB in
|
|
|
|
* size.
|
|
|
|
*/
|
|
|
|
#define FLASH_MAP_BASE_MIN ((hwaddr)(0x100000000ULL - 8*1024*1024))
|
|
|
|
|
|
|
|
/* This function maps flash drives from 4G downward, in order of their unit
|
|
|
|
* numbers. The mapping starts at unit#0, with unit number increments of 1, and
|
|
|
|
* stops before the first missing flash drive, or before
|
|
|
|
* unit#FLASH_MAP_UNIT_MAX, whichever is reached first.
|
|
|
|
*
|
|
|
|
* Addressing within one flash drive is of course not reversed.
|
|
|
|
*
|
|
|
|
* An error message is printed and the process exits if:
|
|
|
|
* - the size of the backing file for a flash drive is non-positive, or not a
|
|
|
|
* multiple of the required sector size, or
|
|
|
|
* - the current mapping's base address would fall below FLASH_MAP_BASE_MIN.
|
|
|
|
*
|
|
|
|
* The drive with unit#0 (if available) is mapped at the highest address, and
|
|
|
|
* it is passed to pc_isa_bios_init(). Merging several drives for isa-bios is
|
|
|
|
* not supported.
|
|
|
|
*/
|
|
|
|
static void pc_system_flash_init(MemoryRegion *rom_memory)
|
2012-02-22 11:18:53 +04:00
|
|
|
{
|
hw/i386/pc_sysfw: support two flash drives
This patch allows the user to usefully specify
-drive file=img_1,if=pflash,format=raw,readonly \
-drive file=img_2,if=pflash,format=raw
on the command line. The flash images will be mapped under 4G in their
reverse unit order -- that is, with their base addresses progressing
downwards, in increasing unit order.
(The unit number increases with command line order if not explicitly
specified.)
This accommodates the following use case: suppose that OVMF is split in
two parts, a writeable host file for non-volatile variable storage, and a
read-only part for bootstrap and decompressible executable code.
The binary code part would be read-only, centrally managed on the host
system, and passed in as unit 0. The variable store would be writeable,
VM-specific, and passed in as unit 1.
00000000ffe00000-00000000ffe1ffff (prio 0, R-): system.flash1
00000000ffe20000-00000000ffffffff (prio 0, R-): system.flash0
(If the guest tries to write to the flash range that is backed by the
read-only drive, pflash_update() is never called; various flash
programming/erase errors are returned to the guest instead. See the
callers of pflash_update(), and the initialization of "pfl->ro", in
"hw/block/pflash_cfi01.c".)
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-11-28 03:52:52 +04:00
|
|
|
int unit;
|
|
|
|
DriveInfo *pflash_drv;
|
2014-10-07 15:59:18 +04:00
|
|
|
BlockBackend *blk;
|
2012-02-22 11:18:53 +04:00
|
|
|
int64_t size;
|
hw/i386/pc_sysfw: support two flash drives
This patch allows the user to usefully specify
-drive file=img_1,if=pflash,format=raw,readonly \
-drive file=img_2,if=pflash,format=raw
on the command line. The flash images will be mapped under 4G in their
reverse unit order -- that is, with their base addresses progressing
downwards, in increasing unit order.
(The unit number increases with command line order if not explicitly
specified.)
This accommodates the following use case: suppose that OVMF is split in
two parts, a writeable host file for non-volatile variable storage, and a
read-only part for bootstrap and decompressible executable code.
The binary code part would be read-only, centrally managed on the host
system, and passed in as unit 0. The variable store would be writeable,
VM-specific, and passed in as unit 1.
00000000ffe00000-00000000ffe1ffff (prio 0, R-): system.flash1
00000000ffe20000-00000000ffffffff (prio 0, R-): system.flash0
(If the guest tries to write to the flash range that is backed by the
read-only drive, pflash_update() is never called; various flash
programming/erase errors are returned to the guest instead. See the
callers of pflash_update(), and the initialization of "pfl->ro", in
"hw/block/pflash_cfi01.c".)
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-11-28 03:52:52 +04:00
|
|
|
char *fatal_errmsg = NULL;
|
|
|
|
hwaddr phys_addr = 0x100000000ULL;
|
2012-02-22 11:18:53 +04:00
|
|
|
int sector_bits, sector_size;
|
|
|
|
pflash_t *system_flash;
|
|
|
|
MemoryRegion *flash_mem;
|
hw/i386/pc_sysfw: support two flash drives
This patch allows the user to usefully specify
-drive file=img_1,if=pflash,format=raw,readonly \
-drive file=img_2,if=pflash,format=raw
on the command line. The flash images will be mapped under 4G in their
reverse unit order -- that is, with their base addresses progressing
downwards, in increasing unit order.
(The unit number increases with command line order if not explicitly
specified.)
This accommodates the following use case: suppose that OVMF is split in
two parts, a writeable host file for non-volatile variable storage, and a
read-only part for bootstrap and decompressible executable code.
The binary code part would be read-only, centrally managed on the host
system, and passed in as unit 0. The variable store would be writeable,
VM-specific, and passed in as unit 1.
00000000ffe00000-00000000ffe1ffff (prio 0, R-): system.flash1
00000000ffe20000-00000000ffffffff (prio 0, R-): system.flash0
(If the guest tries to write to the flash range that is backed by the
read-only drive, pflash_update() is never called; various flash
programming/erase errors are returned to the guest instead. See the
callers of pflash_update(), and the initialization of "pfl->ro", in
"hw/block/pflash_cfi01.c".)
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-11-28 03:52:52 +04:00
|
|
|
char name[64];
|
2012-02-22 11:18:53 +04:00
|
|
|
|
|
|
|
sector_bits = 12;
|
|
|
|
sector_size = 1 << sector_bits;
|
|
|
|
|
hw/i386/pc_sysfw: support two flash drives
This patch allows the user to usefully specify
-drive file=img_1,if=pflash,format=raw,readonly \
-drive file=img_2,if=pflash,format=raw
on the command line. The flash images will be mapped under 4G in their
reverse unit order -- that is, with their base addresses progressing
downwards, in increasing unit order.
(The unit number increases with command line order if not explicitly
specified.)
This accommodates the following use case: suppose that OVMF is split in
two parts, a writeable host file for non-volatile variable storage, and a
read-only part for bootstrap and decompressible executable code.
The binary code part would be read-only, centrally managed on the host
system, and passed in as unit 0. The variable store would be writeable,
VM-specific, and passed in as unit 1.
00000000ffe00000-00000000ffe1ffff (prio 0, R-): system.flash1
00000000ffe20000-00000000ffffffff (prio 0, R-): system.flash0
(If the guest tries to write to the flash range that is backed by the
read-only drive, pflash_update() is never called; various flash
programming/erase errors are returned to the guest instead. See the
callers of pflash_update(), and the initialization of "pfl->ro", in
"hw/block/pflash_cfi01.c".)
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-11-28 03:52:52 +04:00
|
|
|
for (unit = 0;
|
|
|
|
(unit < FLASH_MAP_UNIT_MAX &&
|
|
|
|
(pflash_drv = drive_get(IF_PFLASH, 0, unit)) != NULL);
|
|
|
|
++unit) {
|
2014-10-07 15:59:18 +04:00
|
|
|
blk = blk_by_legacy_dinfo(pflash_drv);
|
|
|
|
size = blk_getlength(blk);
|
hw/i386/pc_sysfw: support two flash drives
This patch allows the user to usefully specify
-drive file=img_1,if=pflash,format=raw,readonly \
-drive file=img_2,if=pflash,format=raw
on the command line. The flash images will be mapped under 4G in their
reverse unit order -- that is, with their base addresses progressing
downwards, in increasing unit order.
(The unit number increases with command line order if not explicitly
specified.)
This accommodates the following use case: suppose that OVMF is split in
two parts, a writeable host file for non-volatile variable storage, and a
read-only part for bootstrap and decompressible executable code.
The binary code part would be read-only, centrally managed on the host
system, and passed in as unit 0. The variable store would be writeable,
VM-specific, and passed in as unit 1.
00000000ffe00000-00000000ffe1ffff (prio 0, R-): system.flash1
00000000ffe20000-00000000ffffffff (prio 0, R-): system.flash0
(If the guest tries to write to the flash range that is backed by the
read-only drive, pflash_update() is never called; various flash
programming/erase errors are returned to the guest instead. See the
callers of pflash_update(), and the initialization of "pfl->ro", in
"hw/block/pflash_cfi01.c".)
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-11-28 03:52:52 +04:00
|
|
|
if (size < 0) {
|
|
|
|
fatal_errmsg = g_strdup_printf("failed to get backing file size");
|
|
|
|
} else if (size == 0) {
|
|
|
|
fatal_errmsg = g_strdup_printf("PC system firmware (pflash) "
|
|
|
|
"cannot have zero size");
|
|
|
|
} else if ((size % sector_size) != 0) {
|
|
|
|
fatal_errmsg = g_strdup_printf("PC system firmware (pflash) "
|
|
|
|
"must be a multiple of 0x%x", sector_size);
|
|
|
|
} else if (phys_addr < size || phys_addr - size < FLASH_MAP_BASE_MIN) {
|
|
|
|
fatal_errmsg = g_strdup_printf("oversized backing file, pflash "
|
|
|
|
"segments cannot be mapped under "
|
|
|
|
TARGET_FMT_plx, FLASH_MAP_BASE_MIN);
|
|
|
|
}
|
|
|
|
if (fatal_errmsg != NULL) {
|
|
|
|
Location loc;
|
|
|
|
|
|
|
|
/* push a new, "none" location on the location stack; overwrite its
|
|
|
|
* contents with the location saved in the option; print the error
|
|
|
|
* (includes location); pop the top
|
|
|
|
*/
|
|
|
|
loc_push_none(&loc);
|
|
|
|
if (pflash_drv->opts != NULL) {
|
|
|
|
qemu_opts_loc_restore(pflash_drv->opts);
|
|
|
|
}
|
|
|
|
error_report("%s", fatal_errmsg);
|
|
|
|
loc_pop(&loc);
|
|
|
|
g_free(fatal_errmsg);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
phys_addr -= size;
|
|
|
|
|
|
|
|
/* pflash_cfi01_register() creates a deep copy of the name */
|
|
|
|
snprintf(name, sizeof name, "system.flash%d", unit);
|
|
|
|
system_flash = pflash_cfi01_register(phys_addr, NULL /* qdev */, name,
|
2014-10-07 15:59:18 +04:00
|
|
|
size, blk, sector_size,
|
hw/i386/pc_sysfw: support two flash drives
This patch allows the user to usefully specify
-drive file=img_1,if=pflash,format=raw,readonly \
-drive file=img_2,if=pflash,format=raw
on the command line. The flash images will be mapped under 4G in their
reverse unit order -- that is, with their base addresses progressing
downwards, in increasing unit order.
(The unit number increases with command line order if not explicitly
specified.)
This accommodates the following use case: suppose that OVMF is split in
two parts, a writeable host file for non-volatile variable storage, and a
read-only part for bootstrap and decompressible executable code.
The binary code part would be read-only, centrally managed on the host
system, and passed in as unit 0. The variable store would be writeable,
VM-specific, and passed in as unit 1.
00000000ffe00000-00000000ffe1ffff (prio 0, R-): system.flash1
00000000ffe20000-00000000ffffffff (prio 0, R-): system.flash0
(If the guest tries to write to the flash range that is backed by the
read-only drive, pflash_update() is never called; various flash
programming/erase errors are returned to the guest instead. See the
callers of pflash_update(), and the initialization of "pfl->ro", in
"hw/block/pflash_cfi01.c".)
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-11-28 03:52:52 +04:00
|
|
|
size >> sector_bits,
|
|
|
|
1 /* width */,
|
|
|
|
0x0000 /* id0 */,
|
|
|
|
0x0000 /* id1 */,
|
|
|
|
0x0000 /* id2 */,
|
|
|
|
0x0000 /* id3 */,
|
|
|
|
0 /* be */);
|
|
|
|
if (unit == 0) {
|
|
|
|
flash_mem = pflash_cfi01_get_memory(system_flash);
|
|
|
|
pc_isa_bios_init(rom_memory, flash_mem, size);
|
|
|
|
}
|
2012-02-22 11:18:53 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-05-29 12:27:24 +04:00
|
|
|
static void old_pc_system_rom_init(MemoryRegion *rom_memory, bool isapc_ram_fw)
|
2012-02-22 11:18:51 +04:00
|
|
|
{
|
|
|
|
char *filename;
|
|
|
|
MemoryRegion *bios, *isa_bios;
|
|
|
|
int bios_size, isa_bios_size;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
/* BIOS load */
|
|
|
|
if (bios_name == NULL) {
|
|
|
|
bios_name = BIOS_FILENAME;
|
|
|
|
}
|
|
|
|
filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
|
|
|
|
if (filename) {
|
|
|
|
bios_size = get_image_size(filename);
|
|
|
|
} else {
|
|
|
|
bios_size = -1;
|
|
|
|
}
|
|
|
|
if (bios_size <= 0 ||
|
|
|
|
(bios_size % 65536) != 0) {
|
|
|
|
goto bios_error;
|
|
|
|
}
|
|
|
|
bios = g_malloc(sizeof(*bios));
|
Fix bad error handling after memory_region_init_ram()
Symptom:
$ qemu-system-x86_64 -m 10000000
Unexpected error in ram_block_add() at /work/armbru/qemu/exec.c:1456:
upstream-qemu: cannot set up guest memory 'pc.ram': Cannot allocate memory
Aborted (core dumped)
Root cause: commit ef701d7 screwed up handling of out-of-memory
conditions. Before the commit, we report the error and exit(1), in
one place, ram_block_add(). The commit lifts the error handling up
the call chain some, to three places. Fine. Except it uses
&error_abort in these places, changing the behavior from exit(1) to
abort(), and thus undoing the work of commit 3922825 "exec: Don't
abort when we can't allocate guest memory".
The three places are:
* memory_region_init_ram()
Commit 4994653 (right after commit ef701d7) lifted the error
handling further, through memory_region_init_ram(), multiplying the
incorrect use of &error_abort. Later on, imitation of existing
(bad) code may have created more.
* memory_region_init_ram_ptr()
The &error_abort is still there.
* memory_region_init_rom_device()
Doesn't need fixing, because commit 33e0eb5 (soon after commit
ef701d7) lifted the error handling further, and in the process
changed it from &error_abort to passing it up the call chain.
Correct, because the callers are realize() methods.
Fix the error handling after memory_region_init_ram() with a
Coccinelle semantic patch:
@r@
expression mr, owner, name, size, err;
position p;
@@
memory_region_init_ram(mr, owner, name, size,
(
- &error_abort
+ &error_fatal
|
err@p
)
);
@script:python@
p << r.p;
@@
print "%s:%s:%s" % (p[0].file, p[0].line, p[0].column)
When the last argument is &error_abort, it gets replaced by
&error_fatal. This is the fix.
If the last argument is anything else, its position is reported. This
lets us check the fix is complete. Four positions get reported:
* ram_backend_memory_alloc()
Error is passed up the call chain, ultimately through
user_creatable_complete(). As far as I can tell, it's callers all
handle the error sanely.
* fsl_imx25_realize(), fsl_imx31_realize(), dp8393x_realize()
DeviceClass.realize() methods, errors handled sanely further up the
call chain.
We're good. Test case again behaves:
$ qemu-system-x86_64 -m 10000000
qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory
[Exit 1 ]
The next commits will repair the rest of commit ef701d7's damage.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1441983105-26376-3-git-send-email-armbru@redhat.com>
Reviewed-by: Peter Crosthwaite <crosthwaite.peter@gmail.com>
2015-09-11 17:51:43 +03:00
|
|
|
memory_region_init_ram(bios, NULL, "pc.bios", bios_size, &error_fatal);
|
2012-02-22 11:18:51 +04:00
|
|
|
vmstate_register_ram_global(bios);
|
2013-05-29 12:27:24 +04:00
|
|
|
if (!isapc_ram_fw) {
|
|
|
|
memory_region_set_readonly(bios, true);
|
|
|
|
}
|
2012-02-22 11:18:51 +04:00
|
|
|
ret = rom_add_file_fixed(bios_name, (uint32_t)(-bios_size), -1);
|
|
|
|
if (ret != 0) {
|
|
|
|
bios_error:
|
|
|
|
fprintf(stderr, "qemu: could not load PC BIOS '%s'\n", bios_name);
|
|
|
|
exit(1);
|
|
|
|
}
|
2014-12-04 16:46:43 +03:00
|
|
|
g_free(filename);
|
2012-02-22 11:18:51 +04:00
|
|
|
|
|
|
|
/* map the last 128KB of the BIOS in ISA space */
|
|
|
|
isa_bios_size = bios_size;
|
|
|
|
if (isa_bios_size > (128 * 1024)) {
|
|
|
|
isa_bios_size = 128 * 1024;
|
|
|
|
}
|
|
|
|
isa_bios = g_malloc(sizeof(*isa_bios));
|
2013-06-06 13:41:28 +04:00
|
|
|
memory_region_init_alias(isa_bios, NULL, "isa-bios", bios,
|
2012-02-22 11:18:51 +04:00
|
|
|
bios_size - isa_bios_size, isa_bios_size);
|
|
|
|
memory_region_add_subregion_overlap(rom_memory,
|
|
|
|
0x100000 - isa_bios_size,
|
|
|
|
isa_bios,
|
|
|
|
1);
|
2013-05-29 12:27:24 +04:00
|
|
|
if (!isapc_ram_fw) {
|
|
|
|
memory_region_set_readonly(isa_bios, true);
|
|
|
|
}
|
2012-02-22 11:18:51 +04:00
|
|
|
|
|
|
|
/* map all the bios at the top of memory */
|
|
|
|
memory_region_add_subregion(rom_memory,
|
|
|
|
(uint32_t)(-bios_size),
|
|
|
|
bios);
|
|
|
|
}
|
|
|
|
|
2013-08-09 21:35:02 +04:00
|
|
|
void pc_system_firmware_init(MemoryRegion *rom_memory, bool isapc_ram_fw)
|
2012-02-22 11:18:51 +04:00
|
|
|
{
|
2012-02-22 11:18:53 +04:00
|
|
|
DriveInfo *pflash_drv;
|
2012-04-19 02:33:15 +04:00
|
|
|
|
2012-02-22 11:18:53 +04:00
|
|
|
pflash_drv = drive_get(IF_PFLASH, 0, 0);
|
|
|
|
|
2013-08-09 21:35:02 +04:00
|
|
|
if (isapc_ram_fw || pflash_drv == NULL) {
|
2013-05-29 12:27:27 +04:00
|
|
|
/* When a pflash drive is not found, use rom-mode */
|
2013-08-09 21:35:02 +04:00
|
|
|
old_pc_system_rom_init(rom_memory, isapc_ram_fw);
|
2013-05-29 12:27:27 +04:00
|
|
|
return;
|
2012-02-22 11:18:53 +04:00
|
|
|
}
|
|
|
|
|
2013-08-09 21:35:01 +04:00
|
|
|
if (kvm_enabled() && !kvm_readonly_mem_enabled()) {
|
|
|
|
/* Older KVM cannot execute from device memory. So, flash memory
|
|
|
|
* cannot be used unless the readonly memory kvm capability is present. */
|
|
|
|
fprintf(stderr, "qemu: pflash with kvm requires KVM readonly memory support\n");
|
2012-02-22 11:18:53 +04:00
|
|
|
exit(1);
|
|
|
|
}
|
2013-08-09 21:35:01 +04:00
|
|
|
|
hw/i386/pc_sysfw: support two flash drives
This patch allows the user to usefully specify
-drive file=img_1,if=pflash,format=raw,readonly \
-drive file=img_2,if=pflash,format=raw
on the command line. The flash images will be mapped under 4G in their
reverse unit order -- that is, with their base addresses progressing
downwards, in increasing unit order.
(The unit number increases with command line order if not explicitly
specified.)
This accommodates the following use case: suppose that OVMF is split in
two parts, a writeable host file for non-volatile variable storage, and a
read-only part for bootstrap and decompressible executable code.
The binary code part would be read-only, centrally managed on the host
system, and passed in as unit 0. The variable store would be writeable,
VM-specific, and passed in as unit 1.
00000000ffe00000-00000000ffe1ffff (prio 0, R-): system.flash1
00000000ffe20000-00000000ffffffff (prio 0, R-): system.flash0
(If the guest tries to write to the flash range that is backed by the
read-only drive, pflash_update() is never called; various flash
programming/erase errors are returned to the guest instead. See the
callers of pflash_update(), and the initialization of "pfl->ro", in
"hw/block/pflash_cfi01.c".)
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-11-28 03:52:52 +04:00
|
|
|
pc_system_flash_init(rom_memory);
|
2012-02-22 11:18:51 +04:00
|
|
|
}
|