qemu-e2k/hw/moxie/moxiesim.c

162 lines
5.3 KiB
C
Raw Normal View History

/*
* QEMU/moxiesim emulation
*
* Emulates a very simple machine model similar to the one used by the
* GDB moxie simulator.
*
* Copyright (c) 2008, 2009, 2010, 2013 Anthony Green
*
* 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.
*/
#include "hw/sysbus.h"
#include "hw/hw.h"
#include "hw/i386/pc.h"
#include "hw/isa/isa.h"
#include "net/net.h"
#include "sysemu/sysemu.h"
#include "hw/boards.h"
#include "hw/loader.h"
#include "hw/char/serial.h"
#include "exec/address-spaces.h"
#define PHYS_MEM_BASE 0x80000000
typedef struct {
uint64_t ram_size;
const char *kernel_filename;
const char *kernel_cmdline;
const char *initrd_filename;
} LoaderParams;
static void load_kernel(MoxieCPU *cpu, LoaderParams *loader_params)
{
uint64_t entry, kernel_low, kernel_high;
long kernel_size;
long initrd_size;
ram_addr_t initrd_offset;
kernel_size = load_elf(loader_params->kernel_filename, NULL, NULL,
&entry, &kernel_low, &kernel_high, 1,
ELF_MACHINE, 0);
if (kernel_size <= 0) {
fprintf(stderr, "qemu: could not load kernel '%s'\n",
loader_params->kernel_filename);
exit(1);
}
/* load initrd */
initrd_size = 0;
initrd_offset = 0;
if (loader_params->initrd_filename) {
initrd_size = get_image_size(loader_params->initrd_filename);
if (initrd_size > 0) {
initrd_offset = (kernel_high + ~TARGET_PAGE_MASK)
& TARGET_PAGE_MASK;
if (initrd_offset + initrd_size > loader_params->ram_size) {
fprintf(stderr,
"qemu: memory too small for initial ram disk '%s'\n",
loader_params->initrd_filename);
exit(1);
}
initrd_size = load_image_targphys(loader_params->initrd_filename,
initrd_offset,
ram_size);
}
if (initrd_size == (target_ulong)-1) {
fprintf(stderr, "qemu: could not load initial ram disk '%s'\n",
loader_params->initrd_filename);
exit(1);
}
}
}
static void main_cpu_reset(void *opaque)
{
MoxieCPU *cpu = opaque;
cpu_reset(CPU(cpu));
}
static void moxiesim_init(MachineState *machine)
{
MoxieCPU *cpu = NULL;
ram_addr_t ram_size = machine->ram_size;
const char *cpu_model = machine->cpu_model;
const char *kernel_filename = machine->kernel_filename;
const char *kernel_cmdline = machine->kernel_cmdline;
const char *initrd_filename = machine->initrd_filename;
CPUMoxieState *env;
MemoryRegion *address_space_mem = get_system_memory();
MemoryRegion *ram = g_new(MemoryRegion, 1);
MemoryRegion *rom = g_new(MemoryRegion, 1);
hwaddr ram_base = 0x200000;
LoaderParams loader_params;
/* Init CPUs. */
if (cpu_model == NULL) {
cpu_model = "MoxieLite-moxie-cpu";
}
cpu = cpu_moxie_init(cpu_model);
if (!cpu) {
fprintf(stderr, "Unable to find CPU definition\n");
exit(1);
}
env = &cpu->env;
qemu_register_reset(main_cpu_reset, cpu);
/* Allocate RAM. */
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 16:51:43 +02:00
memory_region_init_ram(ram, NULL, "moxiesim.ram", ram_size, &error_fatal);
vmstate_register_ram_global(ram);
memory_region_add_subregion(address_space_mem, ram_base, ram);
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 16:51:43 +02:00
memory_region_init_ram(rom, NULL, "moxie.rom", 128*0x1000, &error_fatal);
vmstate_register_ram_global(rom);
memory_region_add_subregion(get_system_memory(), 0x1000, rom);
if (kernel_filename) {
loader_params.ram_size = ram_size;
loader_params.kernel_filename = kernel_filename;
loader_params.kernel_cmdline = kernel_cmdline;
loader_params.initrd_filename = initrd_filename;
load_kernel(cpu, &loader_params);
}
/* A single 16450 sits at offset 0x3f8. */
if (serial_hds[0]) {
serial_mm_init(address_space_mem, 0x3f8, 0, env->irq[4],
8000000/16, serial_hds[0], DEVICE_LITTLE_ENDIAN);
}
}
static QEMUMachine moxiesim_machine = {
.name = "moxiesim",
.desc = "Moxie simulator platform",
.init = moxiesim_init,
.is_default = 1,
};
static void moxie_machine_init(void)
{
qemu_register_machine(&moxiesim_machine);
}
machine_init(moxie_machine_init)