qemu-e2k/include/hw/boards.h

59 lines
1.4 KiB
C
Raw Normal View History

/* Declarations for use by board files for creating devices. */
#ifndef HW_BOARDS_H
#define HW_BOARDS_H
#include "sysemu/blockdev.h"
#include "sysemu/qemumachine.h"
#include "hw/qdev.h"
typedef struct QEMUMachineInitArgs {
const QEMUMachine *machine;
ram_addr_t ram_size;
const char *boot_order;
const char *kernel_filename;
const char *kernel_cmdline;
const char *initrd_filename;
const char *cpu_model;
} QEMUMachineInitArgs;
typedef void QEMUMachineInitFunc(QEMUMachineInitArgs *args);
Allow QEMUMachine to override reset sequencing qemu_system_reset() function always performs the same basic actions on all machines. This includes running all the reset handler hooks, however the order in which these will run is not always easily predictable. This patch splits the core of qemu_system_reset() - the invocation of the reset handlers - out into a new qemu_devices_reset() function. qemu_system_reset() will usually call qemu_devices_reset(), but that can be now overriden by a new reset method in the QEMUMachine structure. Individual machines can use this reset method, if necessary, to perform any extra, machine specific initializations which have to occur before or after the bulk of the reset handlers. It's expected that the method will call qemu_devices_reset() at some point, but if the machine has really strange ordering requirements between devices resets it could even override that with it's own reset sequence (with great care, obviously). For a specific example of when this might be needed: a number of machines (but not PC) load images specified with -kernel or -initrd directly into the machine RAM before booting the guest. This mostly works at the moment, but to make this actually safe requires that this load occurs after peripheral devices are reset - otherwise they could have active DMAs in progress which would clobber the in memory images. Some machines (notably pseries) also have other entry conditions which need to be set up as the last thing before executing in guest space - some of this could be considered "emulated firmware" in the sense that the actions of the firmware are emulated directly by qemu rather than by executing a firmware image within the guest. When the platform's firmware to OS interface is sufficiently well specified, this saves time both in implementing the "firmware" and executing it. aliguori: don't unconditionally dereference current_machine Reviewed-by: Andreas Färber <afaerber@suse.de> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-08-07 08:41:51 +02:00
typedef void QEMUMachineResetFunc(void);
typedef void QEMUMachineHotAddCPUFunc(const int64_t id, Error **errp);
typedef int QEMUMachineGetKvmtypeFunc(const char *arg);
struct QEMUMachine {
const char *name;
const char *alias;
const char *desc;
QEMUMachineInitFunc *init;
Allow QEMUMachine to override reset sequencing qemu_system_reset() function always performs the same basic actions on all machines. This includes running all the reset handler hooks, however the order in which these will run is not always easily predictable. This patch splits the core of qemu_system_reset() - the invocation of the reset handlers - out into a new qemu_devices_reset() function. qemu_system_reset() will usually call qemu_devices_reset(), but that can be now overriden by a new reset method in the QEMUMachine structure. Individual machines can use this reset method, if necessary, to perform any extra, machine specific initializations which have to occur before or after the bulk of the reset handlers. It's expected that the method will call qemu_devices_reset() at some point, but if the machine has really strange ordering requirements between devices resets it could even override that with it's own reset sequence (with great care, obviously). For a specific example of when this might be needed: a number of machines (but not PC) load images specified with -kernel or -initrd directly into the machine RAM before booting the guest. This mostly works at the moment, but to make this actually safe requires that this load occurs after peripheral devices are reset - otherwise they could have active DMAs in progress which would clobber the in memory images. Some machines (notably pseries) also have other entry conditions which need to be set up as the last thing before executing in guest space - some of this could be considered "emulated firmware" in the sense that the actions of the firmware are emulated directly by qemu rather than by executing a firmware image within the guest. When the platform's firmware to OS interface is sufficiently well specified, this saves time both in implementing the "firmware" and executing it. aliguori: don't unconditionally dereference current_machine Reviewed-by: Andreas Färber <afaerber@suse.de> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-08-07 08:41:51 +02:00
QEMUMachineResetFunc *reset;
QEMUMachineHotAddCPUFunc *hot_add_cpu;
QEMUMachineGetKvmtypeFunc *kvm_type;
Support default block interfaces per QEMUMachine There are QEMUMachines that have neither IF_IDE nor IF_SCSI as a default/standard interface to their block devices / drives. Therefore, this patch introduces a new field default_block_type per QEMUMachine struct. The prior use_scsi field becomes thereby obsolete and is replaced through .default_block_type = IF_SCSI. This patch also changes the default for s390x to IF_VIRTIO and removes an early hack that converts IF_IDE drives. Other parties have already claimed interest (e.g. IF_SD for exynos) To create a sane default, for machines that dont specify a default_block_type, this patch makes IF_IDE = 0 and IF_NONE = 1. I checked all users of IF_NONE (blockdev.c and ww/device-hotplug.c) as well as IF_IDE and it seems that it is ok to change the defines - in other words, I found no obvious (to me) assumption in the code regarding IF_NONE==0. IF_NONE is only set if there is an explicit if=none. Without if=* the interface becomes IF_DEFAULT. I would suggest to have some additional care, e.g. by letting this patch sit some days in the block tree. Based on an initial patch from Einar Lueck <elelueck@de.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> CC: Igor Mitsyanko <i.mitsyanko@samsung.com> CC: Markus Armbruster <armbru@redhat.com> CC: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Alexander Graf <agraf@suse.de> Acked-by: Igor Mitsyanko <i.mitsyanko@samsung.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2012-11-20 15:30:34 +01:00
BlockInterfaceType block_default_type;
int max_cpus;
unsigned int no_serial:1,
no_parallel:1,
use_virtcon:1,
use_sclp:1,
no_floppy:1,
no_cdrom:1,
no_sdcard:1;
int is_default;
const char *default_machine_opts;
const char *default_boot_order;
GlobalProperty *compat_props;
struct QEMUMachine *next;
const char *hw_version;
};
int qemu_register_machine(QEMUMachine *m);
QEMUMachine *find_default_machine(void);
extern QEMUMachine *current_machine;
#endif