* [Qemu-devel] [PATCH v3 1/7] Allow boards to specify maximum RAM size
2011-03-29 14:08 [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct Peter Maydell
@ 2011-03-29 14:08 ` Peter Maydell
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 2/7] hw: Add maximum RAM specifications for ARM devboard models Peter Maydell
` (6 subsequent siblings)
7 siblings, 0 replies; 22+ messages in thread
From: Peter Maydell @ 2011-03-29 14:08 UTC (permalink / raw)
To: qemu-devel; +Cc: Blue Swirl, patches
Allow boards to specify their maximum RAM size in the QEMUMachine struct.
This allows us to provide a useful diagnostic if the user tries to specify
a RAM size that the board cannot support.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
hw/boards.h | 1 +
vl.c | 16 +++++++++++++++-
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/hw/boards.h b/hw/boards.h
index 6f0f0d7..5f41fce 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -19,6 +19,7 @@ typedef struct QEMUMachine {
QEMUMachineInitFunc *init;
int use_scsi;
int max_cpus;
+ target_phys_addr_t max_ram;
unsigned int no_serial:1,
no_parallel:1,
use_virtcon:1,
diff --git a/vl.c b/vl.c
index 192a240..69cb29b 100644
--- a/vl.c
+++ b/vl.c
@@ -166,6 +166,9 @@ int main(int argc, char **argv)
//#define DEBUG_NET
//#define DEBUG_SLIRP
+/* Note that this default RAM size is capped to any maximum
+ * RAM size specified in the board's QEMUMachine struct.
+ */
#define DEFAULT_RAM_SIZE 128
#define MAX_VIRTIO_CONSOLES 1
@@ -3046,8 +3049,19 @@ int main(int argc, char **argv, char **envp)
exit(1);
/* init the memory */
- if (ram_size == 0)
+ if (ram_size == 0) {
ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
+ if (machine->max_ram) {
+ ram_size = MIN(ram_size, machine->max_ram);
+ }
+ } else if (machine->max_ram && ram_size > machine->max_ram) {
+ /* Since you can only specify ram_size on the command line in MB it's
+ * OK to round down when printing the machine's maximum.
+ */
+ fprintf(stderr, "qemu: maximum permitted RAM size for '%s' is %ldM\n",
+ machine->name, (ram_addr_t)(machine->max_ram / (1024 * 1024)));
+ exit(1);
+ }
/* init the dynamic translator */
cpu_exec_init_all(tb_size * 1024 * 1024);
--
1.7.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [Qemu-devel] [PATCH v3 2/7] hw: Add maximum RAM specifications for ARM devboard models
2011-03-29 14:08 [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct Peter Maydell
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 1/7] Allow boards to specify maximum RAM size Peter Maydell
@ 2011-03-29 14:08 ` Peter Maydell
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 3/7] vl.c: Fix machine registration so QEMUMachine structs can be const Peter Maydell
` (5 subsequent siblings)
7 siblings, 0 replies; 22+ messages in thread
From: Peter Maydell @ 2011-03-29 14:08 UTC (permalink / raw)
To: qemu-devel; +Cc: Blue Swirl, patches
Specify the maximum memory permitted for the various ARM devboard
models (integratorcp, realview-eb, realview-eb-mpcore, realview-pb-a8,
realview-pbx-a9, versatilepb, versatileab). This means we now handle
attempts to specify too much RAM gracefully rather than causing
the guest to crash in an obscure fashion.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
hw/integratorcp.c | 1 +
hw/realview.c | 11 +++++++++++
hw/versatilepb.c | 5 +++++
3 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/hw/integratorcp.c b/hw/integratorcp.c
index b049940..ccc44db 100644
--- a/hw/integratorcp.c
+++ b/hw/integratorcp.c
@@ -516,6 +516,7 @@ static QEMUMachine integratorcp_machine = {
.name = "integratorcp",
.desc = "ARM Integrator/CP (ARM926EJ-S)",
.init = integratorcp_init,
+ .max_ram = 256 * 1024 * 1024,
.is_default = 1,
};
diff --git a/hw/realview.c b/hw/realview.c
index a67861e..a158ade 100644
--- a/hw/realview.c
+++ b/hw/realview.c
@@ -432,6 +432,7 @@ static QEMUMachine realview_eb_machine = {
.desc = "ARM RealView Emulation Baseboard (ARM926EJ-S)",
.init = realview_eb_init,
.use_scsi = 1,
+ .max_ram = 256 * 1024 * 1024,
};
static QEMUMachine realview_eb_mpcore_machine = {
@@ -440,12 +441,18 @@ static QEMUMachine realview_eb_mpcore_machine = {
.init = realview_eb_mpcore_init,
.use_scsi = 1,
.max_cpus = 4,
+ .max_ram = 256 * 1024 * 1024,
};
static QEMUMachine realview_pb_a8_machine = {
.name = "realview-pb-a8",
.desc = "ARM RealView Platform Baseboard for Cortex-A8",
.init = realview_pb_a8_init,
+ /* The PB-A8 has 512MB; qemu also supports an extra PBX-A9-like
+ * 512MB although strictly speaking that area of the address
+ * space is 'reserved' on the PB-A8.
+ */
+ .max_ram = 1024 * 1024 * 1024,
};
static QEMUMachine realview_pbx_a9_machine = {
@@ -454,6 +461,10 @@ static QEMUMachine realview_pbx_a9_machine = {
.init = realview_pbx_a9_init,
.use_scsi = 1,
.max_cpus = 4,
+ /* Realview PBX has 1GB of RAM (512MB on the motherboard
+ * and another 512MB on the daughterboard)
+ */
+ .max_ram = 1024 * 1024 * 1024,
};
static void realview_machine_init(void)
diff --git a/hw/versatilepb.c b/hw/versatilepb.c
index 9f1bfcf..aeddd28 100644
--- a/hw/versatilepb.c
+++ b/hw/versatilepb.c
@@ -329,6 +329,10 @@ static QEMUMachine versatilepb_machine = {
.desc = "ARM Versatile/PB (ARM926EJ-S)",
.init = vpb_init,
.use_scsi = 1,
+ /* Hardware allows for up to 512MB expansion memory in two
+ * non-contiguous sections, but we only support up to 256MB
+ */
+ .max_ram = 256 * 1024 * 1024,
};
static QEMUMachine versatileab_machine = {
@@ -336,6 +340,7 @@ static QEMUMachine versatileab_machine = {
.desc = "ARM Versatile/AB (ARM926EJ-S)",
.init = vab_init,
.use_scsi = 1,
+ .max_ram = 256 * 1024 * 1024,
};
static void versatile_machine_init(void)
--
1.7.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [Qemu-devel] [PATCH v3 3/7] vl.c: Fix machine registration so QEMUMachine structs can be const
2011-03-29 14:08 [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct Peter Maydell
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 1/7] Allow boards to specify maximum RAM size Peter Maydell
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 2/7] hw: Add maximum RAM specifications for ARM devboard models Peter Maydell
@ 2011-03-29 14:08 ` Peter Maydell
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 4/7] hw/sun4m: Move QEMUMachine structs into sun4*_hwdef structs Peter Maydell
` (4 subsequent siblings)
7 siblings, 0 replies; 22+ messages in thread
From: Peter Maydell @ 2011-03-29 14:08 UTC (permalink / raw)
To: qemu-devel; +Cc: Blue Swirl, patches
Reimplement the list of QEMUMachine structures so that we don't keep the
'next' pointer inside the QEMUMachine struct itself. This allows us to
accept a const struct pointer in qemu_register_machine. The few places
in vl.c which were implicitly assuming that QEMUMachine structs were
writable have been updated.
We also take the opportunity to correct the return type of
qemu_register_machine from 'int' to 'void', since it can never fail
and none of its callers check the return value.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
hw/boards.h | 5 +--
vl.c | 99 ++++++++++++++++++++++++++++++++++------------------------
2 files changed, 60 insertions(+), 44 deletions(-)
diff --git a/hw/boards.h b/hw/boards.h
index 5f41fce..731d8c7 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -29,11 +29,10 @@ typedef struct QEMUMachine {
no_sdcard:1;
int is_default;
GlobalProperty *compat_props;
- struct QEMUMachine *next;
} QEMUMachine;
-int qemu_register_machine(QEMUMachine *m);
+void qemu_register_machine(const QEMUMachine *m);
-extern QEMUMachine *current_machine;
+extern const QEMUMachine *current_machine;
#endif
diff --git a/vl.c b/vl.c
index 69cb29b..d58bbf8 100644
--- a/vl.c
+++ b/vl.c
@@ -1090,45 +1090,62 @@ int qemu_set_fd_handler(int fd,
/***********************************************************/
/* machine registration */
-static QEMUMachine *first_machine = NULL;
-QEMUMachine *current_machine = NULL;
+typedef struct QEMUMachineListEntry {
+ QTAILQ_ENTRY(QEMUMachineListEntry) entry;
+ const QEMUMachine *machine;
+} QEMUMachineListEntry;
-int qemu_register_machine(QEMUMachine *m)
+static QTAILQ_HEAD(machine_list, QEMUMachineListEntry) machine_list =
+ QTAILQ_HEAD_INITIALIZER(machine_list);
+
+const QEMUMachine *current_machine = NULL;
+
+void qemu_register_machine(const QEMUMachine *m)
{
- QEMUMachine **pm;
- pm = &first_machine;
- while (*pm != NULL)
- pm = &(*pm)->next;
- m->next = NULL;
- *pm = m;
- return 0;
+ QEMUMachineListEntry *me = qemu_mallocz(sizeof(QEMUMachineListEntry));
+ me->machine = m;
+ QTAILQ_INSERT_TAIL(&machine_list, me, entry);
}
-static QEMUMachine *find_machine(const char *name)
+static const QEMUMachine *find_machine(const char *name)
{
- QEMUMachine *m;
+ QEMUMachineListEntry *me;
- for(m = first_machine; m != NULL; m = m->next) {
- if (!strcmp(m->name, name))
- return m;
- if (m->alias && !strcmp(m->alias, name))
- return m;
+ QTAILQ_FOREACH(me, &machine_list, entry) {
+ if (!strcmp(me->machine->name, name)) {
+ return me->machine;
+ }
+ if (me->machine->alias && !strcmp(me->machine->alias, name)) {
+ return me->machine;
+ }
}
return NULL;
}
-static QEMUMachine *find_default_machine(void)
+static const QEMUMachine *find_default_machine(void)
{
- QEMUMachine *m;
-
- for(m = first_machine; m != NULL; m = m->next) {
- if (m->is_default) {
- return m;
+ QEMUMachineListEntry *me;
+ QTAILQ_FOREACH(me, &machine_list, entry) {
+ if (me->machine->is_default) {
+ return me->machine;
}
}
return NULL;
}
+static void print_machines(void)
+{
+ QEMUMachineListEntry *me;
+ QTAILQ_FOREACH(me, &machine_list, entry) {
+ const QEMUMachine *m = me->machine;
+ if (m->alias) {
+ printf("%-10s %s (alias of %s)\n", m->alias, m->desc, m->name);
+ }
+ printf("%-10s %s%s\n", m->name, m->desc,
+ m->is_default ? " (default)" : "");
+ }
+}
+
/***********************************************************/
/* main execution loop */
@@ -2050,7 +2067,7 @@ int main(int argc, char **argv, char **envp)
int optind;
const char *optarg;
const char *loadvm = NULL;
- QEMUMachine *machine;
+ const QEMUMachine *machine;
const char *cpu_model;
int tb_size;
const char *pid_file = NULL;
@@ -2146,16 +2163,8 @@ int main(int argc, char **argv, char **envp)
case QEMU_OPTION_M:
machine = find_machine(optarg);
if (!machine) {
- QEMUMachine *m;
printf("Supported machines are:\n");
- for(m = first_machine; m != NULL; m = m->next) {
- if (m->alias)
- printf("%-10s %s (alias of %s)\n",
- m->alias, m->desc, m->name);
- printf("%-10s %s%s\n",
- m->name, m->desc,
- m->is_default ? " (default)" : "");
- }
+ print_machines();
exit(*optarg != '?');
}
break;
@@ -2926,12 +2935,14 @@ int main(int argc, char **argv, char **envp)
if (!max_cpus)
max_cpus = smp_cpus;
- machine->max_cpus = machine->max_cpus ?: 1; /* Default to UP */
- if (smp_cpus > machine->max_cpus) {
- fprintf(stderr, "Number of SMP cpus requested (%d), exceeds max cpus "
- "supported by machine `%s' (%d)\n", smp_cpus, machine->name,
- machine->max_cpus);
- exit(1);
+ {
+ int machine_max_cpus = MAX(machine->max_cpus, 1);
+ if (smp_cpus > machine_max_cpus) {
+ fprintf(stderr, "Number of SMP cpus requested (%d), exceeds max "
+ "cpus supported by machine `%s' (%d)\n",
+ smp_cpus, machine->name, machine_max_cpus);
+ exit(1);
+ }
}
qemu_opts_foreach(qemu_find_opts("device"), default_driver_check, NULL, 0);
@@ -3073,8 +3084,14 @@ int main(int argc, char **argv, char **envp)
/* open the virtual block devices */
if (snapshot)
qemu_opts_foreach(qemu_find_opts("drive"), drive_enable_snapshot, NULL, 0);
- if (qemu_opts_foreach(qemu_find_opts("drive"), drive_init_func, &machine->use_scsi, 1) != 0)
- exit(1);
+
+ {
+ int use_scsi = machine->use_scsi;
+ if (qemu_opts_foreach(qemu_find_opts("drive"), drive_init_func,
+ &use_scsi, 1) != 0) {
+ exit(1);
+ }
+ }
default_drive(default_cdrom, snapshot, machine->use_scsi,
IF_DEFAULT, 2, CDROM_OPTS);
--
1.7.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [Qemu-devel] [PATCH v3 4/7] hw/sun4m: Move QEMUMachine structs into sun4*_hwdef structs
2011-03-29 14:08 [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct Peter Maydell
` (2 preceding siblings ...)
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 3/7] vl.c: Fix machine registration so QEMUMachine structs can be const Peter Maydell
@ 2011-03-29 14:08 ` Peter Maydell
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 5/7] hw/sun4m: Use the QEMUMachine max_ram to implement memory limit Peter Maydell
` (3 subsequent siblings)
7 siblings, 0 replies; 22+ messages in thread
From: Peter Maydell @ 2011-03-29 14:08 UTC (permalink / raw)
To: qemu-devel; +Cc: Blue Swirl, patches
Combine the per-machine QEMUMachine struct into the per-machine
sun4*_hwdef struct. This requires some moving around of init functions
to avoid forward references.
The motivation is to allow the init functions to get at the
QEMUMachine struct for the board, so we can use its max_ram field
rather than having a max_mem field in the sun4*_hwdef struct.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
hw/sun4m.c | 527 ++++++++++++++++++++++++++++++------------------------------
1 files changed, 262 insertions(+), 265 deletions(-)
diff --git a/hw/sun4m.c b/hw/sun4m.c
index df3aa32..bd9ef91 100644
--- a/hw/sun4m.c
+++ b/hw/sun4m.c
@@ -87,6 +87,7 @@
#define ESCC_CLOCK 4915200
struct sun4m_hwdef {
+ QEMUMachine machine;
target_phys_addr_t iommu_base, iommu_pad_base, iommu_pad_len, slavio_base;
target_phys_addr_t intctl_base, counter_base, nvram_base, ms_kb_base;
target_phys_addr_t serial_base, fd_base;
@@ -108,6 +109,7 @@ struct sun4m_hwdef {
#define MAX_IOUNITS 5
struct sun4d_hwdef {
+ QEMUMachine machine;
target_phys_addr_t iounit_bases[MAX_IOUNITS], slavio_base;
target_phys_addr_t counter_base, nvram_base, ms_kb_base;
target_phys_addr_t serial_base;
@@ -123,6 +125,7 @@ struct sun4d_hwdef {
};
struct sun4c_hwdef {
+ QEMUMachine machine;
target_phys_addr_t iommu_base, slavio_base;
target_phys_addr_t intctl_base, counter_base, nvram_base, ms_kb_base;
target_phys_addr_t serial_base, fd_base;
@@ -1006,9 +1009,109 @@ enum {
ss2000_id,
};
+static const struct sun4m_hwdef sun4m_hwdefs[];
+
+/* SPARCstation 5 hardware initialisation */
+static void ss5_init(ram_addr_t RAM_size,
+ const char *boot_device,
+ const char *kernel_filename, const char *kernel_cmdline,
+ const char *initrd_filename, const char *cpu_model)
+{
+ sun4m_hw_init(&sun4m_hwdefs[0], RAM_size, boot_device, kernel_filename,
+ kernel_cmdline, initrd_filename, cpu_model);
+}
+
+/* SPARCstation 10 hardware initialisation */
+static void ss10_init(ram_addr_t RAM_size,
+ const char *boot_device,
+ const char *kernel_filename, const char *kernel_cmdline,
+ const char *initrd_filename, const char *cpu_model)
+{
+ sun4m_hw_init(&sun4m_hwdefs[1], RAM_size, boot_device, kernel_filename,
+ kernel_cmdline, initrd_filename, cpu_model);
+}
+
+/* SPARCserver 600MP hardware initialisation */
+static void ss600mp_init(ram_addr_t RAM_size,
+ const char *boot_device,
+ const char *kernel_filename,
+ const char *kernel_cmdline,
+ const char *initrd_filename, const char *cpu_model)
+{
+ sun4m_hw_init(&sun4m_hwdefs[2], RAM_size, boot_device, kernel_filename,
+ kernel_cmdline, initrd_filename, cpu_model);
+}
+
+/* SPARCstation 20 hardware initialisation */
+static void ss20_init(ram_addr_t RAM_size,
+ const char *boot_device,
+ const char *kernel_filename, const char *kernel_cmdline,
+ const char *initrd_filename, const char *cpu_model)
+{
+ sun4m_hw_init(&sun4m_hwdefs[3], RAM_size, boot_device, kernel_filename,
+ kernel_cmdline, initrd_filename, cpu_model);
+}
+
+/* SPARCstation Voyager hardware initialisation */
+static void vger_init(ram_addr_t RAM_size,
+ const char *boot_device,
+ const char *kernel_filename, const char *kernel_cmdline,
+ const char *initrd_filename, const char *cpu_model)
+{
+ sun4m_hw_init(&sun4m_hwdefs[4], RAM_size, boot_device, kernel_filename,
+ kernel_cmdline, initrd_filename, cpu_model);
+}
+
+/* SPARCstation LX hardware initialisation */
+static void ss_lx_init(ram_addr_t RAM_size,
+ const char *boot_device,
+ const char *kernel_filename, const char *kernel_cmdline,
+ const char *initrd_filename, const char *cpu_model)
+{
+ sun4m_hw_init(&sun4m_hwdefs[5], RAM_size, boot_device, kernel_filename,
+ kernel_cmdline, initrd_filename, cpu_model);
+}
+
+/* SPARCstation 4 hardware initialisation */
+static void ss4_init(ram_addr_t RAM_size,
+ const char *boot_device,
+ const char *kernel_filename, const char *kernel_cmdline,
+ const char *initrd_filename, const char *cpu_model)
+{
+ sun4m_hw_init(&sun4m_hwdefs[6], RAM_size, boot_device, kernel_filename,
+ kernel_cmdline, initrd_filename, cpu_model);
+}
+
+/* SPARCClassic hardware initialisation */
+static void scls_init(ram_addr_t RAM_size,
+ const char *boot_device,
+ const char *kernel_filename, const char *kernel_cmdline,
+ const char *initrd_filename, const char *cpu_model)
+{
+ sun4m_hw_init(&sun4m_hwdefs[7], RAM_size, boot_device, kernel_filename,
+ kernel_cmdline, initrd_filename, cpu_model);
+}
+
+/* SPARCbook hardware initialisation */
+static void sbook_init(ram_addr_t RAM_size,
+ const char *boot_device,
+ const char *kernel_filename, const char *kernel_cmdline,
+ const char *initrd_filename, const char *cpu_model)
+{
+ sun4m_hw_init(&sun4m_hwdefs[8], RAM_size, boot_device, kernel_filename,
+ kernel_cmdline, initrd_filename, cpu_model);
+}
+
static const struct sun4m_hwdef sun4m_hwdefs[] = {
/* SS-5 */
{
+ .machine = {
+ .name = "SS-5",
+ .desc = "Sun4m platform, SPARCstation 5",
+ .init = ss5_init,
+ .use_scsi = 1,
+ .is_default = 1,
+ },
.iommu_base = 0x10000000,
.iommu_pad_base = 0x10004000,
.iommu_pad_len = 0x0fffb000,
@@ -1037,6 +1140,13 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
},
/* SS-10 */
{
+ .machine = {
+ .name = "SS-10",
+ .desc = "Sun4m platform, SPARCstation 10",
+ .init = ss10_init,
+ .use_scsi = 1,
+ .max_cpus = 4,
+ },
.iommu_base = 0xfe0000000ULL,
.tcx_base = 0xe20000000ULL,
.slavio_base = 0xff0000000ULL,
@@ -1063,6 +1173,13 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
},
/* SS-600MP */
{
+ .machine = {
+ .name = "SS-600MP",
+ .desc = "Sun4m platform, SPARCserver 600MP",
+ .init = ss600mp_init,
+ .use_scsi = 1,
+ .max_cpus = 4,
+ },
.iommu_base = 0xfe0000000ULL,
.tcx_base = 0xe20000000ULL,
.slavio_base = 0xff0000000ULL,
@@ -1087,6 +1204,13 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
},
/* SS-20 */
{
+ .machine = {
+ .name = "SS-20",
+ .desc = "Sun4m platform, SPARCstation 20",
+ .init = ss20_init,
+ .use_scsi = 1,
+ .max_cpus = 4,
+ },
.iommu_base = 0xfe0000000ULL,
.tcx_base = 0xe20000000ULL,
.slavio_base = 0xff0000000ULL,
@@ -1129,6 +1253,12 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
},
/* Voyager */
{
+ .machine = {
+ .name = "Voyager",
+ .desc = "Sun4m platform, SPARCstation Voyager",
+ .init = vger_init,
+ .use_scsi = 1,
+ },
.iommu_base = 0x10000000,
.tcx_base = 0x50000000,
.slavio_base = 0x70000000,
@@ -1153,6 +1283,12 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
},
/* LX */
{
+ .machine = {
+ .name = "LX",
+ .desc = "Sun4m platform, SPARCstation LX",
+ .init = ss_lx_init,
+ .use_scsi = 1,
+ },
.iommu_base = 0x10000000,
.iommu_pad_base = 0x10004000,
.iommu_pad_len = 0x0fffb000,
@@ -1178,6 +1314,12 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
},
/* SS-4 */
{
+ .machine = {
+ .name = "SS-4",
+ .desc = "Sun4m platform, SPARCstation 4",
+ .init = ss4_init,
+ .use_scsi = 1,
+ },
.iommu_base = 0x10000000,
.tcx_base = 0x50000000,
.cs_base = 0x6c000000,
@@ -1203,6 +1345,12 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
},
/* SPARCClassic */
{
+ .machine = {
+ .name = "SPARCClassic",
+ .desc = "Sun4m platform, SPARCClassic",
+ .init = scls_init,
+ .use_scsi = 1,
+ },
.iommu_base = 0x10000000,
.tcx_base = 0x50000000,
.slavio_base = 0x70000000,
@@ -1227,6 +1375,12 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
},
/* SPARCbook */
{
+ .machine = {
+ .name = "SPARCbook",
+ .desc = "Sun4m platform, SPARCbook",
+ .init = sbook_init,
+ .use_scsi = 1,
+ },
.iommu_base = 0x10000000,
.tcx_base = 0x50000000, // XXX
.slavio_base = 0x70000000,
@@ -1251,219 +1405,6 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
},
};
-/* SPARCstation 5 hardware initialisation */
-static void ss5_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4m_hw_init(&sun4m_hwdefs[0], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
-
-/* SPARCstation 10 hardware initialisation */
-static void ss10_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4m_hw_init(&sun4m_hwdefs[1], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
-
-/* SPARCserver 600MP hardware initialisation */
-static void ss600mp_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename,
- const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4m_hw_init(&sun4m_hwdefs[2], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
-
-/* SPARCstation 20 hardware initialisation */
-static void ss20_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4m_hw_init(&sun4m_hwdefs[3], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
-
-/* SPARCstation Voyager hardware initialisation */
-static void vger_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4m_hw_init(&sun4m_hwdefs[4], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
-
-/* SPARCstation LX hardware initialisation */
-static void ss_lx_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4m_hw_init(&sun4m_hwdefs[5], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
-
-/* SPARCstation 4 hardware initialisation */
-static void ss4_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4m_hw_init(&sun4m_hwdefs[6], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
-
-/* SPARCClassic hardware initialisation */
-static void scls_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4m_hw_init(&sun4m_hwdefs[7], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
-
-/* SPARCbook hardware initialisation */
-static void sbook_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4m_hw_init(&sun4m_hwdefs[8], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
-
-static QEMUMachine ss5_machine = {
- .name = "SS-5",
- .desc = "Sun4m platform, SPARCstation 5",
- .init = ss5_init,
- .use_scsi = 1,
- .is_default = 1,
-};
-
-static QEMUMachine ss10_machine = {
- .name = "SS-10",
- .desc = "Sun4m platform, SPARCstation 10",
- .init = ss10_init,
- .use_scsi = 1,
- .max_cpus = 4,
-};
-
-static QEMUMachine ss600mp_machine = {
- .name = "SS-600MP",
- .desc = "Sun4m platform, SPARCserver 600MP",
- .init = ss600mp_init,
- .use_scsi = 1,
- .max_cpus = 4,
-};
-
-static QEMUMachine ss20_machine = {
- .name = "SS-20",
- .desc = "Sun4m platform, SPARCstation 20",
- .init = ss20_init,
- .use_scsi = 1,
- .max_cpus = 4,
-};
-
-static QEMUMachine voyager_machine = {
- .name = "Voyager",
- .desc = "Sun4m platform, SPARCstation Voyager",
- .init = vger_init,
- .use_scsi = 1,
-};
-
-static QEMUMachine ss_lx_machine = {
- .name = "LX",
- .desc = "Sun4m platform, SPARCstation LX",
- .init = ss_lx_init,
- .use_scsi = 1,
-};
-
-static QEMUMachine ss4_machine = {
- .name = "SS-4",
- .desc = "Sun4m platform, SPARCstation 4",
- .init = ss4_init,
- .use_scsi = 1,
-};
-
-static QEMUMachine scls_machine = {
- .name = "SPARCClassic",
- .desc = "Sun4m platform, SPARCClassic",
- .init = scls_init,
- .use_scsi = 1,
-};
-
-static QEMUMachine sbook_machine = {
- .name = "SPARCbook",
- .desc = "Sun4m platform, SPARCbook",
- .init = sbook_init,
- .use_scsi = 1,
-};
-
-static const struct sun4d_hwdef sun4d_hwdefs[] = {
- /* SS-1000 */
- {
- .iounit_bases = {
- 0xfe0200000ULL,
- 0xfe1200000ULL,
- 0xfe2200000ULL,
- 0xfe3200000ULL,
- -1,
- },
- .tcx_base = 0x820000000ULL,
- .slavio_base = 0xf00000000ULL,
- .ms_kb_base = 0xf00240000ULL,
- .serial_base = 0xf00200000ULL,
- .nvram_base = 0xf00280000ULL,
- .counter_base = 0xf00300000ULL,
- .espdma_base = 0x800081000ULL,
- .esp_base = 0x800080000ULL,
- .ledma_base = 0x800040000ULL,
- .le_base = 0x800060000ULL,
- .sbi_base = 0xf02800000ULL,
- .nvram_machine_id = 0x80,
- .machine_id = ss1000_id,
- .iounit_version = 0x03000000,
- .max_mem = 0xf00000000ULL,
- .default_cpu_model = "TI SuperSparc II",
- },
- /* SS-2000 */
- {
- .iounit_bases = {
- 0xfe0200000ULL,
- 0xfe1200000ULL,
- 0xfe2200000ULL,
- 0xfe3200000ULL,
- 0xfe4200000ULL,
- },
- .tcx_base = 0x820000000ULL,
- .slavio_base = 0xf00000000ULL,
- .ms_kb_base = 0xf00240000ULL,
- .serial_base = 0xf00200000ULL,
- .nvram_base = 0xf00280000ULL,
- .counter_base = 0xf00300000ULL,
- .espdma_base = 0x800081000ULL,
- .esp_base = 0x800080000ULL,
- .ledma_base = 0x800040000ULL,
- .le_base = 0x800060000ULL,
- .sbi_base = 0xf02800000ULL,
- .nvram_machine_id = 0x80,
- .machine_id = ss2000_id,
- .iounit_version = 0x03000000,
- .max_mem = 0xf00000000ULL,
- .default_cpu_model = "TI SuperSparc II",
- },
-};
-
static DeviceState *sbi_init(target_phys_addr_t addr, qemu_irq **parent_irq)
{
DeviceState *dev;
@@ -1599,6 +1540,8 @@ static void sun4d_hw_init(const struct sun4d_hwdef *hwdef, ram_addr_t RAM_size,
qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
}
+static const struct sun4d_hwdef sun4d_hwdefs[];
+
/* SPARCserver 1000 hardware initialisation */
static void ss1000_init(ram_addr_t RAM_size,
const char *boot_device,
@@ -1619,42 +1562,72 @@ static void ss2000_init(ram_addr_t RAM_size,
kernel_cmdline, initrd_filename, cpu_model);
}
-static QEMUMachine ss1000_machine = {
- .name = "SS-1000",
- .desc = "Sun4d platform, SPARCserver 1000",
- .init = ss1000_init,
- .use_scsi = 1,
- .max_cpus = 8,
-};
-
-static QEMUMachine ss2000_machine = {
- .name = "SS-2000",
- .desc = "Sun4d platform, SPARCcenter 2000",
- .init = ss2000_init,
- .use_scsi = 1,
- .max_cpus = 20,
-};
-
-static const struct sun4c_hwdef sun4c_hwdefs[] = {
- /* SS-2 */
+static const struct sun4d_hwdef sun4d_hwdefs[] = {
+ /* SS-1000 */
{
- .iommu_base = 0xf8000000,
- .tcx_base = 0xfe000000,
- .slavio_base = 0xf6000000,
- .intctl_base = 0xf5000000,
- .counter_base = 0xf3000000,
- .ms_kb_base = 0xf0000000,
- .serial_base = 0xf1000000,
- .nvram_base = 0xf2000000,
- .fd_base = 0xf7200000,
- .dma_base = 0xf8400000,
- .esp_base = 0xf8800000,
- .le_base = 0xf8c00000,
- .aux1_base = 0xf7400003,
- .nvram_machine_id = 0x55,
- .machine_id = ss2_id,
- .max_mem = 0x10000000,
- .default_cpu_model = "Cypress CY7C601",
+ .machine = {
+ .name = "SS-1000",
+ .desc = "Sun4d platform, SPARCserver 1000",
+ .init = ss1000_init,
+ .use_scsi = 1,
+ .max_cpus = 8,
+ },
+ .iounit_bases = {
+ 0xfe0200000ULL,
+ 0xfe1200000ULL,
+ 0xfe2200000ULL,
+ 0xfe3200000ULL,
+ -1,
+ },
+ .tcx_base = 0x820000000ULL,
+ .slavio_base = 0xf00000000ULL,
+ .ms_kb_base = 0xf00240000ULL,
+ .serial_base = 0xf00200000ULL,
+ .nvram_base = 0xf00280000ULL,
+ .counter_base = 0xf00300000ULL,
+ .espdma_base = 0x800081000ULL,
+ .esp_base = 0x800080000ULL,
+ .ledma_base = 0x800040000ULL,
+ .le_base = 0x800060000ULL,
+ .sbi_base = 0xf02800000ULL,
+ .nvram_machine_id = 0x80,
+ .machine_id = ss1000_id,
+ .iounit_version = 0x03000000,
+ .max_mem = 0xf00000000ULL,
+ .default_cpu_model = "TI SuperSparc II",
+ },
+ /* SS-2000 */
+ {
+ .machine = {
+ .name = "SS-2000",
+ .desc = "Sun4d platform, SPARCcenter 2000",
+ .init = ss2000_init,
+ .use_scsi = 1,
+ .max_cpus = 20,
+ },
+ .iounit_bases = {
+ 0xfe0200000ULL,
+ 0xfe1200000ULL,
+ 0xfe2200000ULL,
+ 0xfe3200000ULL,
+ 0xfe4200000ULL,
+ },
+ .tcx_base = 0x820000000ULL,
+ .slavio_base = 0xf00000000ULL,
+ .ms_kb_base = 0xf00240000ULL,
+ .serial_base = 0xf00200000ULL,
+ .nvram_base = 0xf00280000ULL,
+ .counter_base = 0xf00300000ULL,
+ .espdma_base = 0x800081000ULL,
+ .esp_base = 0x800080000ULL,
+ .ledma_base = 0x800040000ULL,
+ .le_base = 0x800060000ULL,
+ .sbi_base = 0xf02800000ULL,
+ .nvram_machine_id = 0x80,
+ .machine_id = ss2000_id,
+ .iounit_version = 0x03000000,
+ .max_mem = 0xf00000000ULL,
+ .default_cpu_model = "TI SuperSparc II",
},
};
@@ -1791,6 +1764,8 @@ static void sun4c_hw_init(const struct sun4c_hwdef *hwdef, ram_addr_t RAM_size,
qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
}
+static const struct sun4c_hwdef sun4c_hwdefs[];
+
/* SPARCstation 2 hardware initialisation */
static void ss2_init(ram_addr_t RAM_size,
const char *boot_device,
@@ -1801,27 +1776,49 @@ static void ss2_init(ram_addr_t RAM_size,
kernel_cmdline, initrd_filename, cpu_model);
}
-static QEMUMachine ss2_machine = {
- .name = "SS-2",
- .desc = "Sun4c platform, SPARCstation 2",
- .init = ss2_init,
- .use_scsi = 1,
+static const struct sun4c_hwdef sun4c_hwdefs[] = {
+ /* SS-2 */
+ {
+ .machine = {
+ .name = "SS-2",
+ .desc = "Sun4c platform, SPARCstation 2",
+ .init = ss2_init,
+ .use_scsi = 1,
+ },
+ .iommu_base = 0xf8000000,
+ .tcx_base = 0xfe000000,
+ .slavio_base = 0xf6000000,
+ .intctl_base = 0xf5000000,
+ .counter_base = 0xf3000000,
+ .ms_kb_base = 0xf0000000,
+ .serial_base = 0xf1000000,
+ .nvram_base = 0xf2000000,
+ .fd_base = 0xf7200000,
+ .dma_base = 0xf8400000,
+ .esp_base = 0xf8800000,
+ .le_base = 0xf8c00000,
+ .aux1_base = 0xf7400003,
+ .nvram_machine_id = 0x55,
+ .machine_id = ss2_id,
+ .max_mem = 0x10000000,
+ .default_cpu_model = "Cypress CY7C601",
+ },
};
static void ss2_machine_init(void)
{
- qemu_register_machine(&ss5_machine);
- qemu_register_machine(&ss10_machine);
- qemu_register_machine(&ss600mp_machine);
- qemu_register_machine(&ss20_machine);
- qemu_register_machine(&voyager_machine);
- qemu_register_machine(&ss_lx_machine);
- qemu_register_machine(&ss4_machine);
- qemu_register_machine(&scls_machine);
- qemu_register_machine(&sbook_machine);
- qemu_register_machine(&ss1000_machine);
- qemu_register_machine(&ss2000_machine);
- qemu_register_machine(&ss2_machine);
+ int i;
+ for (i = 0; i < ARRAY_SIZE(sun4m_hwdefs); i++) {
+ qemu_register_machine(&sun4m_hwdefs[i].machine);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(sun4d_hwdefs); i++) {
+ qemu_register_machine(&sun4d_hwdefs[i].machine);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(sun4c_hwdefs); i++) {
+ qemu_register_machine(&sun4c_hwdefs[i].machine);
+ }
}
machine_init(ss2_machine_init);
--
1.7.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [Qemu-devel] [PATCH v3 5/7] hw/sun4m: Use the QEMUMachine max_ram to implement memory limit
2011-03-29 14:08 [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct Peter Maydell
` (3 preceding siblings ...)
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 4/7] hw/sun4m: Move QEMUMachine structs into sun4*_hwdef structs Peter Maydell
@ 2011-03-29 14:08 ` Peter Maydell
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 6/7] hw/sun4m: Use a macro to hide the repetitive board init functions Peter Maydell
` (2 subsequent siblings)
7 siblings, 0 replies; 22+ messages in thread
From: Peter Maydell @ 2011-03-29 14:08 UTC (permalink / raw)
To: qemu-devel; +Cc: Blue Swirl, patches
Use the max_ram field in QEMUMachine to indicate maximum memory,
rather than a field in the sun4*_hwdef structure. This allows us
to use the vl.c check on RAM specifications rather than having to
code our own.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
hw/sun4m.c | 42 ++++++++++++++++--------------------------
1 files changed, 16 insertions(+), 26 deletions(-)
diff --git a/hw/sun4m.c b/hw/sun4m.c
index bd9ef91..2ae8c45 100644
--- a/hw/sun4m.c
+++ b/hw/sun4m.c
@@ -102,7 +102,6 @@ struct sun4m_hwdef {
uint8_t nvram_machine_id;
uint16_t machine_id;
uint32_t iommu_version;
- uint64_t max_mem;
const char * const default_cpu_model;
};
@@ -120,7 +119,6 @@ struct sun4d_hwdef {
uint8_t nvram_machine_id;
uint16_t machine_id;
uint32_t iounit_version;
- uint64_t max_mem;
const char * const default_cpu_model;
};
@@ -134,7 +132,6 @@ struct sun4c_hwdef {
uint8_t nvram_machine_id;
uint16_t machine_id;
uint32_t iommu_version;
- uint64_t max_mem;
const char * const default_cpu_model;
};
@@ -746,13 +743,6 @@ static void ram_init(target_phys_addr_t addr, ram_addr_t RAM_size,
RamDevice *d;
/* allocate RAM */
- if ((uint64_t)RAM_size > max_mem) {
- fprintf(stderr,
- "qemu: Too much memory for this machine: %d, maximum %d\n",
- (unsigned int)(RAM_size / (1024 * 1024)),
- (unsigned int)(max_mem / (1024 * 1024)));
- exit(1);
- }
dev = qdev_create(NULL, "memory");
s = sysbus_from_qdev(dev);
@@ -833,10 +823,10 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef, ram_addr_t RAM_size,
/* set up devices */
- ram_init(0, RAM_size, hwdef->max_mem);
+ ram_init(0, RAM_size, hwdef->machine.max_ram);
/* models without ECC don't trap when missing ram is accessed */
if (!hwdef->ecc_base) {
- empty_slot_init(RAM_size, hwdef->max_mem - RAM_size);
+ empty_slot_init(RAM_size, hwdef->machine.max_ram - RAM_size);
}
prom_init(hwdef->slavio_base, bios_name);
@@ -1110,6 +1100,7 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
.desc = "Sun4m platform, SPARCstation 5",
.init = ss5_init,
.use_scsi = 1,
+ .max_ram = 0x10000000,
.is_default = 1,
},
.iommu_base = 0x10000000,
@@ -1135,7 +1126,6 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
.nvram_machine_id = 0x80,
.machine_id = ss5_id,
.iommu_version = 0x05000000,
- .max_mem = 0x10000000,
.default_cpu_model = "Fujitsu MB86904",
},
/* SS-10 */
@@ -1146,6 +1136,7 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
.init = ss10_init,
.use_scsi = 1,
.max_cpus = 4,
+ .max_ram = 0xf00000000ULL,
},
.iommu_base = 0xfe0000000ULL,
.tcx_base = 0xe20000000ULL,
@@ -1168,7 +1159,6 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
.nvram_machine_id = 0x72,
.machine_id = ss10_id,
.iommu_version = 0x03000000,
- .max_mem = 0xf00000000ULL,
.default_cpu_model = "TI SuperSparc II",
},
/* SS-600MP */
@@ -1179,6 +1169,7 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
.init = ss600mp_init,
.use_scsi = 1,
.max_cpus = 4,
+ .max_ram = 0xf00000000ULL,
},
.iommu_base = 0xfe0000000ULL,
.tcx_base = 0xe20000000ULL,
@@ -1199,7 +1190,6 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
.nvram_machine_id = 0x71,
.machine_id = ss600mp_id,
.iommu_version = 0x01000000,
- .max_mem = 0xf00000000ULL,
.default_cpu_model = "TI SuperSparc II",
},
/* SS-20 */
@@ -1210,6 +1200,7 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
.init = ss20_init,
.use_scsi = 1,
.max_cpus = 4,
+ .max_ram = 0xf00000000ULL,
},
.iommu_base = 0xfe0000000ULL,
.tcx_base = 0xe20000000ULL,
@@ -1248,7 +1239,6 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
.nvram_machine_id = 0x72,
.machine_id = ss20_id,
.iommu_version = 0x13000000,
- .max_mem = 0xf00000000ULL,
.default_cpu_model = "TI SuperSparc II",
},
/* Voyager */
@@ -1258,6 +1248,7 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
.desc = "Sun4m platform, SPARCstation Voyager",
.init = vger_init,
.use_scsi = 1,
+ .max_ram = 0x10000000,
},
.iommu_base = 0x10000000,
.tcx_base = 0x50000000,
@@ -1278,7 +1269,6 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
.nvram_machine_id = 0x80,
.machine_id = vger_id,
.iommu_version = 0x05000000,
- .max_mem = 0x10000000,
.default_cpu_model = "Fujitsu MB86904",
},
/* LX */
@@ -1288,6 +1278,7 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
.desc = "Sun4m platform, SPARCstation LX",
.init = ss_lx_init,
.use_scsi = 1,
+ .max_ram = 0x10000000,
},
.iommu_base = 0x10000000,
.iommu_pad_base = 0x10004000,
@@ -1309,7 +1300,6 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
.nvram_machine_id = 0x80,
.machine_id = lx_id,
.iommu_version = 0x04000000,
- .max_mem = 0x10000000,
.default_cpu_model = "TI MicroSparc I",
},
/* SS-4 */
@@ -1319,6 +1309,7 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
.desc = "Sun4m platform, SPARCstation 4",
.init = ss4_init,
.use_scsi = 1,
+ .max_ram = 0x10000000,
},
.iommu_base = 0x10000000,
.tcx_base = 0x50000000,
@@ -1340,7 +1331,6 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
.nvram_machine_id = 0x80,
.machine_id = ss4_id,
.iommu_version = 0x05000000,
- .max_mem = 0x10000000,
.default_cpu_model = "Fujitsu MB86904",
},
/* SPARCClassic */
@@ -1350,6 +1340,7 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
.desc = "Sun4m platform, SPARCClassic",
.init = scls_init,
.use_scsi = 1,
+ .max_ram = 0x10000000,
},
.iommu_base = 0x10000000,
.tcx_base = 0x50000000,
@@ -1370,7 +1361,6 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
.nvram_machine_id = 0x80,
.machine_id = scls_id,
.iommu_version = 0x05000000,
- .max_mem = 0x10000000,
.default_cpu_model = "TI MicroSparc I",
},
/* SPARCbook */
@@ -1380,6 +1370,7 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
.desc = "Sun4m platform, SPARCbook",
.init = sbook_init,
.use_scsi = 1,
+ .max_ram = 0x10000000,
},
.iommu_base = 0x10000000,
.tcx_base = 0x50000000, // XXX
@@ -1400,7 +1391,6 @@ static const struct sun4m_hwdef sun4m_hwdefs[] = {
.nvram_machine_id = 0x80,
.machine_id = sbook_id,
.iommu_version = 0x05000000,
- .max_mem = 0x10000000,
.default_cpu_model = "TI MicroSparc I",
},
};
@@ -1452,7 +1442,7 @@ static void sun4d_hw_init(const struct sun4d_hwdef *hwdef, ram_addr_t RAM_size,
cpu_irqs[i] = qemu_allocate_irqs(dummy_cpu_set_irq, NULL, MAX_PILS);
/* set up devices */
- ram_init(0, RAM_size, hwdef->max_mem);
+ ram_init(0, RAM_size, hwdef->machine.max_ram);
prom_init(hwdef->slavio_base, bios_name);
@@ -1571,6 +1561,7 @@ static const struct sun4d_hwdef sun4d_hwdefs[] = {
.init = ss1000_init,
.use_scsi = 1,
.max_cpus = 8,
+ .max_ram = 0xf00000000ULL,
},
.iounit_bases = {
0xfe0200000ULL,
@@ -1593,7 +1584,6 @@ static const struct sun4d_hwdef sun4d_hwdefs[] = {
.nvram_machine_id = 0x80,
.machine_id = ss1000_id,
.iounit_version = 0x03000000,
- .max_mem = 0xf00000000ULL,
.default_cpu_model = "TI SuperSparc II",
},
/* SS-2000 */
@@ -1604,6 +1594,7 @@ static const struct sun4d_hwdef sun4d_hwdefs[] = {
.init = ss2000_init,
.use_scsi = 1,
.max_cpus = 20,
+ .max_ram = 0xf00000000ULL,
},
.iounit_bases = {
0xfe0200000ULL,
@@ -1626,7 +1617,6 @@ static const struct sun4d_hwdef sun4d_hwdefs[] = {
.nvram_machine_id = 0x80,
.machine_id = ss2000_id,
.iounit_version = 0x03000000,
- .max_mem = 0xf00000000ULL,
.default_cpu_model = "TI SuperSparc II",
},
};
@@ -1674,7 +1664,7 @@ static void sun4c_hw_init(const struct sun4c_hwdef *hwdef, ram_addr_t RAM_size,
cpu_devinit(cpu_model, 0, hwdef->slavio_base, &cpu_irqs);
/* set up devices */
- ram_init(0, RAM_size, hwdef->max_mem);
+ ram_init(0, RAM_size, hwdef->machine.max_ram);
prom_init(hwdef->slavio_base, bios_name);
@@ -1784,6 +1774,7 @@ static const struct sun4c_hwdef sun4c_hwdefs[] = {
.desc = "Sun4c platform, SPARCstation 2",
.init = ss2_init,
.use_scsi = 1,
+ .max_ram = 0x10000000,
},
.iommu_base = 0xf8000000,
.tcx_base = 0xfe000000,
@@ -1800,7 +1791,6 @@ static const struct sun4c_hwdef sun4c_hwdefs[] = {
.aux1_base = 0xf7400003,
.nvram_machine_id = 0x55,
.machine_id = ss2_id,
- .max_mem = 0x10000000,
.default_cpu_model = "Cypress CY7C601",
},
};
--
1.7.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [Qemu-devel] [PATCH v3 6/7] hw/sun4m: Use a macro to hide the repetitive board init functions
2011-03-29 14:08 [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct Peter Maydell
` (4 preceding siblings ...)
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 5/7] hw/sun4m: Use the QEMUMachine max_ram to implement memory limit Peter Maydell
@ 2011-03-29 14:08 ` Peter Maydell
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 7/7] hw: Make QEMUMachine structure definitions const Peter Maydell
2011-03-30 7:48 ` [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct Jes Sorensen
7 siblings, 0 replies; 22+ messages in thread
From: Peter Maydell @ 2011-03-29 14:08 UTC (permalink / raw)
To: qemu-devel; +Cc: Blue Swirl, patches
Tidy up the repetitive board init functions (which are all the same
apart from which hwdef struct they pass in). This also lets us add
an assertion that the hwdef points to the init function which uses
that hwdef, rather than some other one.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
hw/sun4m.c | 138 ++++++++++--------------------------------------------------
1 files changed, 22 insertions(+), 116 deletions(-)
diff --git a/hw/sun4m.c b/hw/sun4m.c
index 2ae8c45..f130fc9 100644
--- a/hw/sun4m.c
+++ b/hw/sun4m.c
@@ -1001,96 +1001,27 @@ enum {
static const struct sun4m_hwdef sun4m_hwdefs[];
-/* SPARCstation 5 hardware initialisation */
-static void ss5_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4m_hw_init(&sun4m_hwdefs[0], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
-
-/* SPARCstation 10 hardware initialisation */
-static void ss10_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4m_hw_init(&sun4m_hwdefs[1], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
-
-/* SPARCserver 600MP hardware initialisation */
-static void ss600mp_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename,
- const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4m_hw_init(&sun4m_hwdefs[2], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
-
-/* SPARCstation 20 hardware initialisation */
-static void ss20_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4m_hw_init(&sun4m_hwdefs[3], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
-
-/* SPARCstation Voyager hardware initialisation */
-static void vger_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4m_hw_init(&sun4m_hwdefs[4], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
+#define SUN4_INITFN(NAME, SUBARCH, OFFSET) \
+static void NAME##_init(ram_addr_t RAM_size, \
+ const char *boot_device, \
+ const char *kernel_filename, const char *kernel_cmdline, \
+ const char *initrd_filename, const char *cpu_model) \
+{ \
+ assert(SUBARCH##_hwdefs[OFFSET].machine.init == NAME##_init); \
+ SUBARCH##_hw_init(&SUBARCH##_hwdefs[OFFSET], RAM_size, boot_device, \
+ kernel_filename, kernel_cmdline, initrd_filename, \
+ cpu_model); \
}
-/* SPARCstation LX hardware initialisation */
-static void ss_lx_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4m_hw_init(&sun4m_hwdefs[5], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
-
-/* SPARCstation 4 hardware initialisation */
-static void ss4_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4m_hw_init(&sun4m_hwdefs[6], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
-
-/* SPARCClassic hardware initialisation */
-static void scls_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4m_hw_init(&sun4m_hwdefs[7], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
-
-/* SPARCbook hardware initialisation */
-static void sbook_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4m_hw_init(&sun4m_hwdefs[8], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
+SUN4_INITFN(ss5, sun4m, 0)
+SUN4_INITFN(ss10, sun4m, 1)
+SUN4_INITFN(ss600mp, sun4m, 2)
+SUN4_INITFN(ss20, sun4m, 3)
+SUN4_INITFN(vger, sun4m, 4)
+SUN4_INITFN(ss_lx, sun4m, 5)
+SUN4_INITFN(ss4, sun4m, 6)
+SUN4_INITFN(scls, sun4m, 7)
+SUN4_INITFN(sbook, sun4m, 8)
static const struct sun4m_hwdef sun4m_hwdefs[] = {
/* SS-5 */
@@ -1532,25 +1463,8 @@ static void sun4d_hw_init(const struct sun4d_hwdef *hwdef, ram_addr_t RAM_size,
static const struct sun4d_hwdef sun4d_hwdefs[];
-/* SPARCserver 1000 hardware initialisation */
-static void ss1000_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4d_hw_init(&sun4d_hwdefs[0], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
-
-/* SPARCcenter 2000 hardware initialisation */
-static void ss2000_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4d_hw_init(&sun4d_hwdefs[1], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
+SUN4_INITFN(ss1000, sun4d, 0)
+SUN4_INITFN(ss2000, sun4d, 1)
static const struct sun4d_hwdef sun4d_hwdefs[] = {
/* SS-1000 */
@@ -1756,15 +1670,7 @@ static void sun4c_hw_init(const struct sun4c_hwdef *hwdef, ram_addr_t RAM_size,
static const struct sun4c_hwdef sun4c_hwdefs[];
-/* SPARCstation 2 hardware initialisation */
-static void ss2_init(ram_addr_t RAM_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
-{
- sun4c_hw_init(&sun4c_hwdefs[0], RAM_size, boot_device, kernel_filename,
- kernel_cmdline, initrd_filename, cpu_model);
-}
+SUN4_INITFN(ss2, sun4c, 0)
static const struct sun4c_hwdef sun4c_hwdefs[] = {
/* SS-2 */
--
1.7.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [Qemu-devel] [PATCH v3 7/7] hw: Make QEMUMachine structure definitions const
2011-03-29 14:08 [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct Peter Maydell
` (5 preceding siblings ...)
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 6/7] hw/sun4m: Use a macro to hide the repetitive board init functions Peter Maydell
@ 2011-03-29 14:08 ` Peter Maydell
2011-03-30 7:48 ` [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct Jes Sorensen
7 siblings, 0 replies; 22+ messages in thread
From: Peter Maydell @ 2011-03-29 14:08 UTC (permalink / raw)
To: qemu-devel; +Cc: Blue Swirl, patches
Now that qemu_register_machine() accepts a const QEMUMachine *, we can
mark all the static QEMUMachine structure definitions for boards as
being const.
This patch was mostly automatically generated via:
sed -i -e 's/^static QEMUMachine /static const QEMUMachine /' hw/*.c
and then checked for completeness with a grep for QEMUMachine, which
showed up the mips_fulong2e and leon3 machines which were missing a
'static' (which has been added here).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
hw/an5206.c | 2 +-
hw/axis_dev88.c | 2 +-
hw/dummy_m68k.c | 2 +-
hw/etraxfs.c | 2 +-
hw/gumstix.c | 4 ++--
hw/integratorcp.c | 2 +-
hw/leon3.c | 2 +-
hw/lm32_boards.c | 4 ++--
hw/mainstone.c | 2 +-
hw/mcf5208.c | 2 +-
hw/mips_fulong2e.c | 2 +-
hw/mips_jazz.c | 4 ++--
hw/mips_malta.c | 2 +-
hw/mips_mipssim.c | 2 +-
hw/mips_r4k.c | 2 +-
hw/musicpal.c | 2 +-
hw/nseries.c | 4 ++--
hw/omap_sx1.c | 4 ++--
hw/palm.c | 2 +-
hw/pc_piix.c | 12 ++++++------
hw/petalogix_ml605_mmu.c | 2 +-
hw/petalogix_s3adsp1800_mmu.c | 2 +-
hw/ppc405_boards.c | 4 ++--
hw/ppc440_bamboo.c | 4 ++--
hw/ppc_newworld.c | 2 +-
hw/ppc_oldworld.c | 2 +-
hw/ppc_prep.c | 2 +-
hw/ppce500_mpc8544ds.c | 2 +-
hw/r2d.c | 2 +-
hw/realview.c | 8 ++++----
hw/s390-virtio.c | 2 +-
hw/shix.c | 2 +-
hw/spitz.c | 8 ++++----
hw/stellaris.c | 4 ++--
hw/sun4u.c | 6 +++---
hw/syborg.c | 2 +-
hw/tosa.c | 2 +-
hw/versatilepb.c | 4 ++--
hw/virtex_ml507.c | 2 +-
hw/xen_machine_pv.c | 2 +-
40 files changed, 62 insertions(+), 62 deletions(-)
diff --git a/hw/an5206.c b/hw/an5206.c
index b9f19a9..8bd70fe 100644
--- a/hw/an5206.c
+++ b/hw/an5206.c
@@ -87,7 +87,7 @@ static void an5206_init(ram_addr_t ram_size,
env->pc = entry;
}
-static QEMUMachine an5206_machine = {
+static const QEMUMachine an5206_machine = {
.name = "an5206",
.desc = "Arnewsh 5206",
.init = an5206_init,
diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c
index 57b5e2f..0aef171 100644
--- a/hw/axis_dev88.c
+++ b/hw/axis_dev88.c
@@ -343,7 +343,7 @@ void axisdev88_init (ram_addr_t ram_size,
cris_load_image(env, &li);
}
-static QEMUMachine axisdev88_machine = {
+static const QEMUMachine axisdev88_machine = {
.name = "axis-dev88",
.desc = "AXIS devboard 88",
.init = axisdev88_init,
diff --git a/hw/dummy_m68k.c b/hw/dummy_m68k.c
index 61efb39..1954282 100644
--- a/hw/dummy_m68k.c
+++ b/hw/dummy_m68k.c
@@ -66,7 +66,7 @@ static void dummy_m68k_init(ram_addr_t ram_size,
env->pc = entry;
}
-static QEMUMachine dummy_m68k_machine = {
+static const QEMUMachine dummy_m68k_machine = {
.name = "dummy",
.desc = "Dummy board",
.init = dummy_m68k_init,
diff --git a/hw/etraxfs.c b/hw/etraxfs.c
index 5ee5f97..7a92b7a 100644
--- a/hw/etraxfs.c
+++ b/hw/etraxfs.c
@@ -145,7 +145,7 @@ void bareetraxfs_init (ram_addr_t ram_size,
}
}
-static QEMUMachine bareetraxfs_machine = {
+static const QEMUMachine bareetraxfs_machine = {
.name = "bareetraxfs",
.desc = "Bare ETRAX FS board",
.init = bareetraxfs_init,
diff --git a/hw/gumstix.c b/hw/gumstix.c
index ee63f63..8eca2ba 100644
--- a/hw/gumstix.c
+++ b/hw/gumstix.c
@@ -120,13 +120,13 @@ static void verdex_init(ram_addr_t ram_size,
qdev_get_gpio_in(cpu->gpio, 99));
}
-static QEMUMachine connex_machine = {
+static const QEMUMachine connex_machine = {
.name = "connex",
.desc = "Gumstix Connex (PXA255)",
.init = connex_init,
};
-static QEMUMachine verdex_machine = {
+static const QEMUMachine verdex_machine = {
.name = "verdex",
.desc = "Gumstix Verdex (PXA270)",
.init = verdex_init,
diff --git a/hw/integratorcp.c b/hw/integratorcp.c
index ccc44db..a7d02ba 100644
--- a/hw/integratorcp.c
+++ b/hw/integratorcp.c
@@ -512,7 +512,7 @@ static void integratorcp_init(ram_addr_t ram_size,
arm_load_kernel(env, &integrator_binfo);
}
-static QEMUMachine integratorcp_machine = {
+static const QEMUMachine integratorcp_machine = {
.name = "integratorcp",
.desc = "ARM Integrator/CP (ARM926EJ-S)",
.init = integratorcp_init,
diff --git a/hw/leon3.c b/hw/leon3.c
index 919f49f..b6ebf52 100644
--- a/hw/leon3.c
+++ b/hw/leon3.c
@@ -202,7 +202,7 @@ static void leon3_generic_hw_init(ram_addr_t ram_size,
}
}
-QEMUMachine leon3_generic_machine = {
+static const QEMUMachine leon3_generic_machine = {
.name = "leon3_generic",
.desc = "Leon-3 generic",
.init = leon3_generic_hw_init,
diff --git a/hw/lm32_boards.c b/hw/lm32_boards.c
index 85190f0..e2b0081 100644
--- a/hw/lm32_boards.c
+++ b/hw/lm32_boards.c
@@ -282,14 +282,14 @@ static void lm32_uclinux_init(ram_addr_t ram_size_not_used,
qemu_register_reset(main_cpu_reset, reset_info);
}
-static QEMUMachine lm32_evr_machine = {
+static const QEMUMachine lm32_evr_machine = {
.name = "lm32-evr",
.desc = "LatticeMico32 EVR32 eval system",
.init = lm32_evr_init,
.is_default = 1
};
-static QEMUMachine lm32_uclinux_machine = {
+static const QEMUMachine lm32_uclinux_machine = {
.name = "lm32-uclinux",
.desc = "lm32 platform for uClinux and u-boot by Theobroma Systems",
.init = lm32_uclinux_init,
diff --git a/hw/mainstone.c b/hw/mainstone.c
index 50691ca..6605d21 100644
--- a/hw/mainstone.c
+++ b/hw/mainstone.c
@@ -175,7 +175,7 @@ static void mainstone_init(ram_addr_t ram_size,
kernel_cmdline, initrd_filename, cpu_model, mainstone, 0x196);
}
-static QEMUMachine mainstone2_machine = {
+static const QEMUMachine mainstone2_machine = {
.name = "mainstone",
.desc = "Mainstone II (PXA27x)",
.init = mainstone_init,
diff --git a/hw/mcf5208.c b/hw/mcf5208.c
index 17a692d..75216a1 100644
--- a/hw/mcf5208.c
+++ b/hw/mcf5208.c
@@ -291,7 +291,7 @@ static void mcf5208evb_init(ram_addr_t ram_size,
env->pc = entry;
}
-static QEMUMachine mcf5208evb_machine = {
+static const QEMUMachine mcf5208evb_machine = {
.name = "mcf5208evb",
.desc = "MCF5206EVB",
.init = mcf5208evb_init,
diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c
index f5ae639..90d16ee 100644
--- a/hw/mips_fulong2e.c
+++ b/hw/mips_fulong2e.c
@@ -394,7 +394,7 @@ static void mips_fulong2e_init(ram_addr_t ram_size, const char *boot_device,
network_init();
}
-QEMUMachine mips_fulong2e_machine = {
+static const QEMUMachine mips_fulong2e_machine = {
.name = "fulong2e",
.desc = "Fulong 2e mini pc",
.init = mips_fulong2e_init,
diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c
index a100394..7aae4dc 100644
--- a/hw/mips_jazz.c
+++ b/hw/mips_jazz.c
@@ -291,14 +291,14 @@ void mips_pica61_init (ram_addr_t ram_size,
mips_jazz_init(ram_size, cpu_model, JAZZ_PICA61);
}
-static QEMUMachine mips_magnum_machine = {
+static const QEMUMachine mips_magnum_machine = {
.name = "magnum",
.desc = "MIPS Magnum",
.init = mips_magnum_init,
.use_scsi = 1,
};
-static QEMUMachine mips_pica61_machine = {
+static const QEMUMachine mips_pica61_machine = {
.name = "pica61",
.desc = "Acer Pica 61",
.init = mips_pica61_init,
diff --git a/hw/mips_malta.c b/hw/mips_malta.c
index d8baa6d..b540f06 100644
--- a/hw/mips_malta.c
+++ b/hw/mips_malta.c
@@ -967,7 +967,7 @@ void mips_malta_init (ram_addr_t ram_size,
}
}
-static QEMUMachine mips_malta_machine = {
+static const QEMUMachine mips_malta_machine = {
.name = "malta",
.desc = "MIPS Malta Core LV",
.init = mips_malta_init,
diff --git a/hw/mips_mipssim.c b/hw/mips_mipssim.c
index 380a7eb..943eb9e 100644
--- a/hw/mips_mipssim.c
+++ b/hw/mips_mipssim.c
@@ -198,7 +198,7 @@ mips_mipssim_init (ram_addr_t ram_size,
mipsnet_init(0x4200, env->irq[2], &nd_table[0]);
}
-static QEMUMachine mips_mipssim_machine = {
+static const QEMUMachine mips_mipssim_machine = {
.name = "mipssim",
.desc = "MIPS MIPSsim platform",
.init = mips_mipssim_init,
diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c
index 8feb461..c224f83 100644
--- a/hw/mips_r4k.c
+++ b/hw/mips_r4k.c
@@ -304,7 +304,7 @@ void mips_r4k_init (ram_addr_t ram_size,
isa_create_simple("i8042");
}
-static QEMUMachine mips_machine = {
+static const QEMUMachine mips_machine = {
.name = "mips",
.desc = "mips r4k platform",
.init = mips_r4k_init,
diff --git a/hw/musicpal.c b/hw/musicpal.c
index d98aa8d..7242c6f 100644
--- a/hw/musicpal.c
+++ b/hw/musicpal.c
@@ -1636,7 +1636,7 @@ static void musicpal_init(ram_addr_t ram_size,
arm_load_kernel(env, &musicpal_binfo);
}
-static QEMUMachine musicpal_machine = {
+static const QEMUMachine musicpal_machine = {
.name = "musicpal",
.desc = "Marvell 88w8618 / MusicPal (ARM926EJ-S)",
.init = musicpal_init,
diff --git a/hw/nseries.c b/hw/nseries.c
index 2f6f473..77258cc 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -1396,13 +1396,13 @@ static void n810_init(ram_addr_t ram_size,
cpu_model, &n810_binfo, 810);
}
-static QEMUMachine n800_machine = {
+static const QEMUMachine n800_machine = {
.name = "n800",
.desc = "Nokia N800 tablet aka. RX-34 (OMAP2420)",
.init = n800_init,
};
-static QEMUMachine n810_machine = {
+static const QEMUMachine n810_machine = {
.name = "n810",
.desc = "Nokia N810 tablet aka. RX-44 (OMAP2420)",
.init = n810_init,
diff --git a/hw/omap_sx1.c b/hw/omap_sx1.c
index 06bccbd..1dfbd28 100644
--- a/hw/omap_sx1.c
+++ b/hw/omap_sx1.c
@@ -233,13 +233,13 @@ static void sx1_init_v2(ram_addr_t ram_size,
kernel_cmdline, initrd_filename, cpu_model, 2);
}
-static QEMUMachine sx1_machine_v2 = {
+static const QEMUMachine sx1_machine_v2 = {
.name = "sx1",
.desc = "Siemens SX1 (OMAP310) V2",
.init = sx1_init_v2,
};
-static QEMUMachine sx1_machine_v1 = {
+static const QEMUMachine sx1_machine_v1 = {
.name = "sx1-v1",
.desc = "Siemens SX1 (OMAP310) V1",
.init = sx1_init_v1,
diff --git a/hw/palm.c b/hw/palm.c
index f22d777..3411222 100644
--- a/hw/palm.c
+++ b/hw/palm.c
@@ -275,7 +275,7 @@ static void palmte_init(ram_addr_t ram_size,
dpy_resize(ds);
}
-static QEMUMachine palmte_machine = {
+static const QEMUMachine palmte_machine = {
.name = "cheetah",
.desc = "Palm Tungsten|E aka. Cheetah PDA (OMAP310)",
.init = palmte_init,
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index b3ede89..1474969 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -227,7 +227,7 @@ static void pc_init_isa(ram_addr_t ram_size,
initrd_filename, cpu_model, 0, 1);
}
-static QEMUMachine pc_machine = {
+static const QEMUMachine pc_machine = {
.name = "pc-0.14",
.alias = "pc",
.desc = "Standard PC",
@@ -236,7 +236,7 @@ static QEMUMachine pc_machine = {
.is_default = 1,
};
-static QEMUMachine pc_machine_v0_13 = {
+static const QEMUMachine pc_machine_v0_13 = {
.name = "pc-0.13",
.desc = "Standard PC",
.init = pc_init_pci_no_kvmclock,
@@ -263,7 +263,7 @@ static QEMUMachine pc_machine_v0_13 = {
},
};
-static QEMUMachine pc_machine_v0_12 = {
+static const QEMUMachine pc_machine_v0_12 = {
.name = "pc-0.12",
.desc = "Standard PC",
.init = pc_init_pci_no_kvmclock,
@@ -294,7 +294,7 @@ static QEMUMachine pc_machine_v0_12 = {
}
};
-static QEMUMachine pc_machine_v0_11 = {
+static const QEMUMachine pc_machine_v0_11 = {
.name = "pc-0.11",
.desc = "Standard PC, qemu 0.11",
.init = pc_init_pci_no_kvmclock,
@@ -333,7 +333,7 @@ static QEMUMachine pc_machine_v0_11 = {
}
};
-static QEMUMachine pc_machine_v0_10 = {
+static const QEMUMachine pc_machine_v0_10 = {
.name = "pc-0.10",
.desc = "Standard PC, qemu 0.10",
.init = pc_init_pci_no_kvmclock,
@@ -384,7 +384,7 @@ static QEMUMachine pc_machine_v0_10 = {
},
};
-static QEMUMachine isapc_machine = {
+static const QEMUMachine isapc_machine = {
.name = "isapc",
.desc = "ISA-only PC",
.init = pc_init_isa,
diff --git a/hw/petalogix_ml605_mmu.c b/hw/petalogix_ml605_mmu.c
index 8213902..1ce6585 100644
--- a/hw/petalogix_ml605_mmu.c
+++ b/hw/petalogix_ml605_mmu.c
@@ -251,7 +251,7 @@ petalogix_ml605_init(ram_addr_t ram_size,
}
}
-static QEMUMachine petalogix_ml605_machine = {
+static const QEMUMachine petalogix_ml605_machine = {
.name = "petalogix-ml605",
.desc = "PetaLogix linux refdesign for xilinx ml605 little endian",
.init = petalogix_ml605_init,
diff --git a/hw/petalogix_s3adsp1800_mmu.c b/hw/petalogix_s3adsp1800_mmu.c
index 4dcdfbd..92c1a4a 100644
--- a/hw/petalogix_s3adsp1800_mmu.c
+++ b/hw/petalogix_s3adsp1800_mmu.c
@@ -215,7 +215,7 @@ petalogix_s3adsp1800_init(ram_addr_t ram_size,
}
}
-static QEMUMachine petalogix_s3adsp1800_machine = {
+static const QEMUMachine petalogix_s3adsp1800_machine = {
.name = "petalogix-s3adsp1800",
.desc = "PetaLogix linux refdesign for xilinx Spartan 3ADSP1800",
.init = petalogix_s3adsp1800_init,
diff --git a/hw/ppc405_boards.c b/hw/ppc405_boards.c
index ad27181..3b3dd57 100644
--- a/hw/ppc405_boards.c
+++ b/hw/ppc405_boards.c
@@ -353,7 +353,7 @@ static void ref405ep_init (ram_addr_t ram_size,
printf("bdloc %016lx\n", (unsigned long)bdloc);
}
-static QEMUMachine ref405ep_machine = {
+static const QEMUMachine ref405ep_machine = {
.name = "ref405ep",
.desc = "ref405ep",
.init = ref405ep_init,
@@ -639,7 +639,7 @@ static void taihu_405ep_init(ram_addr_t ram_size,
#endif
}
-static QEMUMachine taihu_machine = {
+static const QEMUMachine taihu_machine = {
.name = "taihu",
.desc = "taihu",
.init = taihu_405ep_init,
diff --git a/hw/ppc440_bamboo.c b/hw/ppc440_bamboo.c
index 34ddf45..6aef3aa 100644
--- a/hw/ppc440_bamboo.c
+++ b/hw/ppc440_bamboo.c
@@ -169,14 +169,14 @@ static void bamboo_init(ram_addr_t ram_size,
kvmppc_init();
}
-static QEMUMachine bamboo_machine = {
+static const QEMUMachine bamboo_machine = {
.name = "bamboo-0.13",
.alias = "bamboo",
.desc = "bamboo",
.init = bamboo_init,
};
-static QEMUMachine bamboo_machine_v0_12 = {
+static const QEMUMachine bamboo_machine_v0_12 = {
.name = "bamboo-0.12",
.desc = "bamboo",
.init = bamboo_init,
diff --git a/hw/ppc_newworld.c b/hw/ppc_newworld.c
index b9245f0..0b64a4b 100644
--- a/hw/ppc_newworld.c
+++ b/hw/ppc_newworld.c
@@ -411,7 +411,7 @@ static void ppc_core99_init (ram_addr_t ram_size,
qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
}
-static QEMUMachine core99_machine = {
+static const QEMUMachine core99_machine = {
.name = "mac99",
.desc = "Mac99 based PowerMAC",
.init = ppc_core99_init,
diff --git a/hw/ppc_oldworld.c b/hw/ppc_oldworld.c
index 8a4e088..f9d82dd 100644
--- a/hw/ppc_oldworld.c
+++ b/hw/ppc_oldworld.c
@@ -314,7 +314,7 @@ static void ppc_heathrow_init (ram_addr_t ram_size,
qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
}
-static QEMUMachine heathrow_machine = {
+static const QEMUMachine heathrow_machine = {
.name = "g3beige",
.desc = "Heathrow based PowerMAC",
.init = ppc_heathrow_init,
diff --git a/hw/ppc_prep.c b/hw/ppc_prep.c
index 5615ef9..8568ecd 100644
--- a/hw/ppc_prep.c
+++ b/hw/ppc_prep.c
@@ -756,7 +756,7 @@ static void ppc_prep_init (ram_addr_t ram_size,
register_ioport_write(0x0F00, 4, 1, &PPC_debug_write, NULL);
}
-static QEMUMachine prep_machine = {
+static const QEMUMachine prep_machine = {
.name = "prep",
.desc = "PowerPC PREP platform",
.init = ppc_prep_init,
diff --git a/hw/ppce500_mpc8544ds.c b/hw/ppce500_mpc8544ds.c
index b7670ae..7a971b1 100644
--- a/hw/ppce500_mpc8544ds.c
+++ b/hw/ppce500_mpc8544ds.c
@@ -283,7 +283,7 @@ static void mpc8544ds_init(ram_addr_t ram_size,
return;
}
-static QEMUMachine mpc8544ds_machine = {
+static const QEMUMachine mpc8544ds_machine = {
.name = "mpc8544ds",
.desc = "mpc8544ds",
.init = mpc8544ds_init,
diff --git a/hw/r2d.c b/hw/r2d.c
index a0f8c1f..6f948ce 100644
--- a/hw/r2d.c
+++ b/hw/r2d.c
@@ -327,7 +327,7 @@ static void r2d_init(ram_addr_t ram_size,
SDRAM_BASE + BOOT_PARAMS_OFFSET);
}
-static QEMUMachine r2d_machine = {
+static const QEMUMachine r2d_machine = {
.name = "r2d",
.desc = "r2d-plus board",
.init = r2d_init,
diff --git a/hw/realview.c b/hw/realview.c
index a158ade..402e85b 100644
--- a/hw/realview.c
+++ b/hw/realview.c
@@ -427,7 +427,7 @@ static void realview_pbx_a9_init(ram_addr_t ram_size,
initrd_filename, cpu_model, BOARD_PBX_A9);
}
-static QEMUMachine realview_eb_machine = {
+static const QEMUMachine realview_eb_machine = {
.name = "realview-eb",
.desc = "ARM RealView Emulation Baseboard (ARM926EJ-S)",
.init = realview_eb_init,
@@ -435,7 +435,7 @@ static QEMUMachine realview_eb_machine = {
.max_ram = 256 * 1024 * 1024,
};
-static QEMUMachine realview_eb_mpcore_machine = {
+static const QEMUMachine realview_eb_mpcore_machine = {
.name = "realview-eb-mpcore",
.desc = "ARM RealView Emulation Baseboard (ARM11MPCore)",
.init = realview_eb_mpcore_init,
@@ -444,7 +444,7 @@ static QEMUMachine realview_eb_mpcore_machine = {
.max_ram = 256 * 1024 * 1024,
};
-static QEMUMachine realview_pb_a8_machine = {
+static const QEMUMachine realview_pb_a8_machine = {
.name = "realview-pb-a8",
.desc = "ARM RealView Platform Baseboard for Cortex-A8",
.init = realview_pb_a8_init,
@@ -455,7 +455,7 @@ static QEMUMachine realview_pb_a8_machine = {
.max_ram = 1024 * 1024 * 1024,
};
-static QEMUMachine realview_pbx_a9_machine = {
+static const QEMUMachine realview_pbx_a9_machine = {
.name = "realview-pbx-a9",
.desc = "ARM RealView Platform Baseboard Explore for Cortex-A9",
.init = realview_pbx_a9_init,
diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
index 850422f..d8d7bd6 100644
--- a/hw/s390-virtio.c
+++ b/hw/s390-virtio.c
@@ -269,7 +269,7 @@ static void s390_init(ram_addr_t ram_size,
}
}
-static QEMUMachine s390_machine = {
+static const QEMUMachine s390_machine = {
.name = "s390-virtio",
.alias = "s390",
.desc = "VirtIO based S390 machine",
diff --git a/hw/shix.c b/hw/shix.c
index 638bf16..4355070 100644
--- a/hw/shix.c
+++ b/hw/shix.c
@@ -89,7 +89,7 @@ static void shix_init(ram_addr_t ram_size,
fprintf(stderr, "initialization terminated\n");
}
-static QEMUMachine shix_machine = {
+static const QEMUMachine shix_machine = {
.name = "shix",
.desc = "shix card",
.init = shix_init,
diff --git a/hw/spitz.c b/hw/spitz.c
index 006f7a9..d543a90 100644
--- a/hw/spitz.c
+++ b/hw/spitz.c
@@ -980,25 +980,25 @@ static void terrier_init(ram_addr_t ram_size,
kernel_cmdline, initrd_filename, cpu_model, terrier, 0x33f);
}
-static QEMUMachine akitapda_machine = {
+static const QEMUMachine akitapda_machine = {
.name = "akita",
.desc = "Akita PDA (PXA270)",
.init = akita_init,
};
-static QEMUMachine spitzpda_machine = {
+static const QEMUMachine spitzpda_machine = {
.name = "spitz",
.desc = "Spitz PDA (PXA270)",
.init = spitz_init,
};
-static QEMUMachine borzoipda_machine = {
+static const QEMUMachine borzoipda_machine = {
.name = "borzoi",
.desc = "Borzoi PDA (PXA270)",
.init = borzoi_init,
};
-static QEMUMachine terrierpda_machine = {
+static const QEMUMachine terrierpda_machine = {
.name = "terrier",
.desc = "Terrier PDA (PXA270)",
.init = terrier_init,
diff --git a/hw/stellaris.c b/hw/stellaris.c
index 0d52926..4c5239e 100644
--- a/hw/stellaris.c
+++ b/hw/stellaris.c
@@ -1433,13 +1433,13 @@ static void lm3s6965evb_init(ram_addr_t ram_size,
stellaris_init(kernel_filename, cpu_model, &stellaris_boards[1]);
}
-static QEMUMachine lm3s811evb_machine = {
+static const QEMUMachine lm3s811evb_machine = {
.name = "lm3s811evb",
.desc = "Stellaris LM3S811EVB",
.init = lm3s811evb_init,
};
-static QEMUMachine lm3s6965evb_machine = {
+static const QEMUMachine lm3s6965evb_machine = {
.name = "lm3s6965evb",
.desc = "Stellaris LM3S6965EVB",
.init = lm3s6965evb_init,
diff --git a/hw/sun4u.c b/hw/sun4u.c
index dbb5a15..cb41c9f 100644
--- a/hw/sun4u.c
+++ b/hw/sun4u.c
@@ -910,7 +910,7 @@ static void niagara_init(ram_addr_t RAM_size,
kernel_cmdline, initrd_filename, cpu_model, &hwdefs[2]);
}
-static QEMUMachine sun4u_machine = {
+static const QEMUMachine sun4u_machine = {
.name = "sun4u",
.desc = "Sun4u platform",
.init = sun4u_init,
@@ -918,14 +918,14 @@ static QEMUMachine sun4u_machine = {
.is_default = 1,
};
-static QEMUMachine sun4v_machine = {
+static const QEMUMachine sun4v_machine = {
.name = "sun4v",
.desc = "Sun4v platform",
.init = sun4v_init,
.max_cpus = 1, // XXX for now
};
-static QEMUMachine niagara_machine = {
+static const QEMUMachine niagara_machine = {
.name = "Niagara",
.desc = "Sun4v platform, Niagara",
.init = niagara_init,
diff --git a/hw/syborg.c b/hw/syborg.c
index 758c69a..468049b 100644
--- a/hw/syborg.c
+++ b/hw/syborg.c
@@ -98,7 +98,7 @@ static void syborg_init(ram_addr_t ram_size,
arm_load_kernel(env, &syborg_binfo);
}
-static QEMUMachine syborg_machine = {
+static const QEMUMachine syborg_machine = {
.name = "syborg",
.desc = "Syborg (Symbian Virtual Platform)",
.init = syborg_init,
diff --git a/hw/tosa.c b/hw/tosa.c
index b8b6c4f..cddf2cd 100644
--- a/hw/tosa.c
+++ b/hw/tosa.c
@@ -243,7 +243,7 @@ static void tosa_init(ram_addr_t ram_size,
sl_bootparam_write(SL_PXA_PARAM_BASE);
}
-static QEMUMachine tosapda_machine = {
+static const QEMUMachine tosapda_machine = {
.name = "tosa",
.desc = "Tosa PDA (PXA255)",
.init = tosa_init,
diff --git a/hw/versatilepb.c b/hw/versatilepb.c
index aeddd28..3f22124 100644
--- a/hw/versatilepb.c
+++ b/hw/versatilepb.c
@@ -324,7 +324,7 @@ static void vab_init(ram_addr_t ram_size,
initrd_filename, cpu_model, 0x25e);
}
-static QEMUMachine versatilepb_machine = {
+static const QEMUMachine versatilepb_machine = {
.name = "versatilepb",
.desc = "ARM Versatile/PB (ARM926EJ-S)",
.init = vpb_init,
@@ -335,7 +335,7 @@ static QEMUMachine versatilepb_machine = {
.max_ram = 256 * 1024 * 1024,
};
-static QEMUMachine versatileab_machine = {
+static const QEMUMachine versatileab_machine = {
.name = "versatileab",
.desc = "ARM Versatile/AB (ARM926EJ-S)",
.init = vab_init,
diff --git a/hw/virtex_ml507.c b/hw/virtex_ml507.c
index fa60515..e236e0e 100644
--- a/hw/virtex_ml507.c
+++ b/hw/virtex_ml507.c
@@ -262,7 +262,7 @@ static void virtex_init(ram_addr_t ram_size,
env->load_info = &boot_info;
}
-static QEMUMachine virtex_machine = {
+static const QEMUMachine virtex_machine = {
.name = "virtex-ml507",
.desc = "Xilinx Virtex ML507 reference design",
.init = virtex_init,
diff --git a/hw/xen_machine_pv.c b/hw/xen_machine_pv.c
index 77a34bf..2a3346d 100644
--- a/hw/xen_machine_pv.c
+++ b/hw/xen_machine_pv.c
@@ -109,7 +109,7 @@ static void xen_init_pv(ram_addr_t ram_size,
xen_init_display(xen_domid);
}
-static QEMUMachine xenpv_machine = {
+static const QEMUMachine xenpv_machine = {
.name = "xenpv",
.desc = "Xen Para-virtualized PC",
.init = xen_init_pv,
--
1.7.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
2011-03-29 14:08 [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct Peter Maydell
` (6 preceding siblings ...)
2011-03-29 14:08 ` [Qemu-devel] [PATCH v3 7/7] hw: Make QEMUMachine structure definitions const Peter Maydell
@ 2011-03-30 7:48 ` Jes Sorensen
2011-03-30 8:09 ` Peter Maydell
7 siblings, 1 reply; 22+ messages in thread
From: Jes Sorensen @ 2011-03-30 7:48 UTC (permalink / raw)
To: Peter Maydell; +Cc: Blue Swirl, qemu-devel, patches
On 03/29/11 16:08, Peter Maydell wrote:
> This primary aim of this patchset is to add a new 'max_ram' field to the
> QEMUMachine structure so that a board model can specify the maximum RAM it
> will accept. We can then produce a friendly diagnostic message when the
> user tries to start qemu with a '-m' option asking for more RAM than that.
> (Currently most of the ARM devboard models respond with an obscure guest
> crash when the guest tries to access RAM and finds device registers
> instead.)
>
> If no maximum size is specified we default to the old behaviour of
> "do not impose any limit".
>
> The bulk of the patchset is knock-on cleanup as a result, in particular
> allowing QEMUMachine structs to be const and sun4m cleanup.
Hi Peter,
Sorry for not getting to this patch earlier.
I am a little concerned about this approach. It should work for simple
embedded boards, but for larger systems, it really ought to be a mask
rather than a max address. On NUMA systems you are bound to have holes,
and at times you might not even start from address 0. In these cases you
are likely to have device registers mapped in between the memory chunks.
Ideally I think it would be better to have a mask and then introduce a
is_valid_memory() kinda function to check it with.
I fear that by introducing a simple max limit like this, we are going to
hit problems later when we try to improve the NUMA support.
Cheers,
Jes
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
2011-03-30 7:48 ` [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct Jes Sorensen
@ 2011-03-30 8:09 ` Peter Maydell
2011-03-30 10:51 ` Jes Sorensen
0 siblings, 1 reply; 22+ messages in thread
From: Peter Maydell @ 2011-03-30 8:09 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Blue Swirl, qemu-devel, patches
On 30 March 2011 08:48, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> On 03/29/11 16:08, Peter Maydell wrote:
>> This primary aim of this patchset is to add a new 'max_ram' field to the
>> QEMUMachine structure so that a board model can specify the maximum RAM it
>> will accept.
> I am a little concerned about this approach. It should work for simple
> embedded boards, but for larger systems, it really ought to be a mask
> rather than a max address.
It's not a maximum address, it's a maximum size. For instance
the RAM isn't contiguous on some of the ARM devboards.
> Ideally I think it would be better to have a mask and then introduce a
> is_valid_memory() kinda function to check it with.
The command line option doesn't provide any means of saying
"put 64MB in this hole and another 128 over here and 32 there",
so this seems completely pointless to me. All we are trying
to do is validate what the user has asked for, so why have
a validation mechanism that can cope with impossible-to-request
arrangements?
> I fear that by introducing a simple max limit like this, we are going to
> hit problems later when we try to improve the NUMA support.
I think this is letting the best be the enemy of the good.
Even if you do want to have NUMA systems do more complex
things I think you should still have the simple "maximum
size" approach for the bulk of the supported boards which
don't need anything more complicated. So additional NUMA
features would augment, not replace this.
-- PMM
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
2011-03-30 8:09 ` Peter Maydell
@ 2011-03-30 10:51 ` Jes Sorensen
2011-03-30 13:22 ` Peter Maydell
0 siblings, 1 reply; 22+ messages in thread
From: Jes Sorensen @ 2011-03-30 10:51 UTC (permalink / raw)
To: Peter Maydell; +Cc: Blue Swirl, qemu-devel, patches
On 03/30/11 10:09, Peter Maydell wrote:
> On 30 March 2011 08:48, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
>> I am a little concerned about this approach. It should work for simple
>> embedded boards, but for larger systems, it really ought to be a mask
>> rather than a max address.
>
> It's not a maximum address, it's a maximum size. For instance
> the RAM isn't contiguous on some of the ARM devboards.
Right, but the fact that you can have holes makes it even more an issue.
>> Ideally I think it would be better to have a mask and then introduce a
>> is_valid_memory() kinda function to check it with.
>
> The command line option doesn't provide any means of saying
> "put 64MB in this hole and another 128 over here and 32 there",
> so this seems completely pointless to me. All we are trying
> to do is validate what the user has asked for, so why have
> a validation mechanism that can cope with impossible-to-request
> arrangements?
You can on x86 using the -numa argument. When you use that, it is
completely pointless to have the max memory limit, to use your own words.
>> I fear that by introducing a simple max limit like this, we are going to
>> hit problems later when we try to improve the NUMA support.
>
> I think this is letting the best be the enemy of the good.
>
> Even if you do want to have NUMA systems do more complex
> things I think you should still have the simple "maximum
> size" approach for the bulk of the supported boards which
> don't need anything more complicated. So additional NUMA
> features would augment, not replace this.
The problem is we end up with two mechanisms that way which won't
necessarily live well together.
Since you have holes on ARM too, it makes sense IMHO to use a mask
exactly because you can then map that to max memory by simply adding up
the available holes. A linear number on the other hand is much harder to
validate against once you start populating holes explicitly.
Cheers,
Jes
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
2011-03-30 10:51 ` Jes Sorensen
@ 2011-03-30 13:22 ` Peter Maydell
2011-03-30 13:55 ` Jes Sorensen
2011-03-30 13:56 ` Anthony Liguori
0 siblings, 2 replies; 22+ messages in thread
From: Peter Maydell @ 2011-03-30 13:22 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Blue Swirl, qemu-devel, patches
On 30 March 2011 11:51, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> On 03/30/11 10:09, Peter Maydell wrote:
>> On 30 March 2011 08:48, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
>>> I am a little concerned about this approach. It should work for simple
>>> embedded boards, but for larger systems, it really ought to be a mask
>>> rather than a max address.
>>
>> It's not a maximum address, it's a maximum size. For instance
>> the RAM isn't contiguous on some of the ARM devboards.
>
> Right, but the fact that you can have holes makes it even more an issue.
Not really, typically they're just filled up in some particular
order (main RAM in one place and expansion RAM elsewhere).
Since the board init function is only passed a single "ram_size"
parameter that's all you can do anyhow.
>>> Ideally I think it would be better to have a mask and then introduce a
>>> is_valid_memory() kinda function to check it with.
I'm not sure what this mask would look like. You want megabyte
granularity, but even if you assume only 48 bit physical addresses
that would still be an alarmingly large number of bits. So I
guess you'd actually want a list of (start,length) tuples.
I strongly dislike this approach. I think it introduces unneeded
extra complexity, and it doesn't even address all the cases you
might want a generic "validate RAM options" mechanism to do (eg
boards which only allow RAM in 16MB increments, boards where you
must fill the base RAM first and then the expansion RAM, boards
where the RAM isn't at a specific physical address but can be
remapped under guest control, just to pick three). So it falls
awkwardly between the two stools of "flexible and generic" and
"simple and straightforward".
>> The command line option doesn't provide any means of saying
>> "put 64MB in this hole and another 128 over here and 32 there",
> You can on x86 using the -numa argument. When you use that, it is
> completely pointless to have the max memory limit, to use your own words.
(Is there any documentation on what you can do with the -numa
option? http://qemu.weilnetz.de/qemu-doc.html is decidedly laconic.)
> Since you have holes on ARM too, it makes sense IMHO to use a mask
> exactly because you can then map that to max memory by simply adding up
> the available holes. A linear number on the other hand is much harder to
> validate against once you start populating holes explicitly.
But I don't want to populate holes explicitly, and I don't imagine
most of the other boards want to populate holes explicitly
either.
The current QEMU design basically only controls the total amount
of RAM (as a command line option, and as a parameter to the board
init function), with NUMA being a an optional extra. Non-NUMA is
the common use case and you want the API used by the board code
to be straightforward to implement this common case. Adding a
simple "maximum RAM" field fits in with the existing design and
solves a genuine requirement for multiple board models.
Even if one system happens to have NUMA-specific requirements we
don't want to have to have every single devboard specify its RAM
limits in a complicated fashion for the benefit of the one NUMA
system. Just have the NUMA system not specify max_ram (so it gets
the default of zero, ie "don't check") and have some NUMA-specific
QEMUMachine fields which default to "system doesn't support NUMA".
Then NUMA aware board models can do the right thing, and non-NUMA
boards also do the right thing without having to think about
NUMA-related fields at all.
(Compare the way non-SMP boards don't have to worry about the
max_cpus field.)
-- PMM
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
2011-03-30 13:22 ` Peter Maydell
@ 2011-03-30 13:55 ` Jes Sorensen
2011-03-30 13:56 ` Anthony Liguori
1 sibling, 0 replies; 22+ messages in thread
From: Jes Sorensen @ 2011-03-30 13:55 UTC (permalink / raw)
To: Peter Maydell; +Cc: Blue Swirl, qemu-devel, patches
On 03/30/11 15:22, Peter Maydell wrote:
> On 30 March 2011 11:51, Jes Sorensen <Jes.Sorensen@redhat.com>
> wrote:
>>>> Ideally I think it would be better to have a mask and then
>>>> introduce a is_valid_memory() kinda function to check it with.
>
> I'm not sure what this mask would look like. You want megabyte
> granularity, but even if you assume only 48 bit physical addresses
> that would still be an alarmingly large number of bits. So I guess
> you'd actually want a list of (start,length) tuples.
>
> I strongly dislike this approach. I think it introduces unneeded
> extra complexity, and it doesn't even address all the cases you might
> want a generic "validate RAM options" mechanism to do (eg boards
> which only allow RAM in 16MB increments, boards where you must fill
> the base RAM first and then the expansion RAM, boards where the RAM
> isn't at a specific physical address but can be remapped under guest
> control, just to pick three). So it falls awkwardly between the two
> stools of "flexible and generic" and "simple and straightforward".
I thought about it a bit and obviously a simple mask isn't going to cut
it. What we should have is more like a list of valid ram locations which
we can use to calculate the allowable size for. The -m parameter is
really a shortcut for the real thing, and we shouldn't optimize for -m,
but rather the other way round.
>> You can on x86 using the -numa argument. When you use that, it is
>> completely pointless to have the max memory limit, to use your own
>> words.
>
> (Is there any documentation on what you can do with the -numa option?
> http://qemu.weilnetz.de/qemu-doc.html is decidedly laconic.)
I don't know of documentation for that unfortunately :( Eventually you
should be able to do anything with it that can happen in a real numa
system. Basically it should allow you to define nodes and assign CPUs
and memory to the given nodes, as well as PCI devices.
>> Since you have holes on ARM too, it makes sense IMHO to use a mask
>> exactly because you can then map that to max memory by simply
>> adding up the available holes. A linear number on the other hand is
>> much harder to validate against once you start populating holes
>> explicitly.
>
> But I don't want to populate holes explicitly, and I don't imagine
> most of the other boards want to populate holes explicitly either.
Why not? You just mentioned the case where board holes can be populated
in different ways?
> The current QEMU design basically only controls the total amount of
> RAM (as a command line option, and as a parameter to the board init
> function), with NUMA being a an optional extra. Non-NUMA is the
> common use case and you want the API used by the board code to be
> straightforward to implement this common case. Adding a simple
> "maximum RAM" field fits in with the existing design and solves a
> genuine requirement for multiple board models.
The problem with the existing design is exactly that it was designed for
the simple case, and works badly for the case that matches the hardware
better. I suggest we do it right, and then provide functions to make -m
work easily. Otherwise we end up with bad hacks that are going to work
badly for the non simple case.
> Even if one system happens to have NUMA-specific requirements we
> don't want to have to have every single devboard specify its RAM
> limits in a complicated fashion for the benefit of the one NUMA
> system. Just have the NUMA system not specify max_ram (so it gets the
> default of zero, ie "don't check") and have some NUMA-specific
> QEMUMachine fields which default to "system doesn't support NUMA".
> Then NUMA aware board models can do the right thing, and non-NUMA
> boards also do the right thing without having to think about
> NUMA-related fields at all. (Compare the way non-SMP boards don't
> have to worry about the max_cpus field.)
A simple system is basically a single-node NUMA system. So you refer to
NODE 0 per default if no explicit node is listed. Instead what we should
have is something like this
struct node_memregion {
uint64_t start0, end0;
uint64_t start1, end1;
uint64_t start2, end2;
uint64_t start3, end3;
}
Then have a max-nodes value per machine, and a pointer to a
node_memregion array. If you only have one node, which would be the
common case, then you populate just that specifying the holes you have
etc. A simple function can then calculate the maximum allowable memory
in a generic way.
Simple to define for all the simple boards.
Jes
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
2011-03-30 13:22 ` Peter Maydell
2011-03-30 13:55 ` Jes Sorensen
@ 2011-03-30 13:56 ` Anthony Liguori
2011-03-30 14:07 ` Peter Maydell
1 sibling, 1 reply; 22+ messages in thread
From: Anthony Liguori @ 2011-03-30 13:56 UTC (permalink / raw)
To: Peter Maydell; +Cc: Blue Swirl, Jes Sorensen, qemu-devel, patches
On 03/30/2011 08:22 AM, Peter Maydell wrote:
> On 30 March 2011 11:51, Jes Sorensen<Jes.Sorensen@redhat.com> wrote:
>> On 03/30/11 10:09, Peter Maydell wrote:
>>> On 30 March 2011 08:48, Jes Sorensen<Jes.Sorensen@redhat.com> wrote:
>>>> I am a little concerned about this approach. It should work for simple
>>>> embedded boards, but for larger systems, it really ought to be a mask
>>>> rather than a max address.
>>> It's not a maximum address, it's a maximum size. For instance
>>> the RAM isn't contiguous on some of the ARM devboards.
>> Right, but the fact that you can have holes makes it even more an issue.
> Not really, typically they're just filled up in some particular
> order (main RAM in one place and expansion RAM elsewhere).
> Since the board init function is only passed a single "ram_size"
> parameter that's all you can do anyhow.
FWIW, I don't think any static data is going to be perfect here. A lot
of boards have strict requirements on ram_size based on plausible
combinations of DIMMs. Arbitrary values up to ram_size is not good enough.
ram_size ought to be viewed as a hint, not a mechanism to allow common
code to completely validate the passed in ram size parameter. It's
still up to the board to validate that the given ram size makes sense.
Regards,
Anthony Liguori
>>>> Ideally I think it would be better to have a mask and then introduce a
>>>> is_valid_memory() kinda function to check it with.
> I'm not sure what this mask would look like. You want megabyte
> granularity, but even if you assume only 48 bit physical addresses
> that would still be an alarmingly large number of bits. So I
> guess you'd actually want a list of (start,length) tuples.
>
> I strongly dislike this approach. I think it introduces unneeded
> extra complexity, and it doesn't even address all the cases you
> might want a generic "validate RAM options" mechanism to do (eg
> boards which only allow RAM in 16MB increments, boards where you
> must fill the base RAM first and then the expansion RAM, boards
> where the RAM isn't at a specific physical address but can be
> remapped under guest control, just to pick three). So it falls
> awkwardly between the two stools of "flexible and generic" and
> "simple and straightforward".
>
>>> The command line option doesn't provide any means of saying
>>> "put 64MB in this hole and another 128 over here and 32 there",
>> You can on x86 using the -numa argument. When you use that, it is
>> completely pointless to have the max memory limit, to use your own words.
> (Is there any documentation on what you can do with the -numa
> option? http://qemu.weilnetz.de/qemu-doc.html is decidedly laconic.)
>
>> Since you have holes on ARM too, it makes sense IMHO to use a mask
>> exactly because you can then map that to max memory by simply adding up
>> the available holes. A linear number on the other hand is much harder to
>> validate against once you start populating holes explicitly.
> But I don't want to populate holes explicitly, and I don't imagine
> most of the other boards want to populate holes explicitly
> either.
>
> The current QEMU design basically only controls the total amount
> of RAM (as a command line option, and as a parameter to the board
> init function), with NUMA being a an optional extra. Non-NUMA is
> the common use case and you want the API used by the board code
> to be straightforward to implement this common case. Adding a
> simple "maximum RAM" field fits in with the existing design and
> solves a genuine requirement for multiple board models.
>
> Even if one system happens to have NUMA-specific requirements we
> don't want to have to have every single devboard specify its RAM
> limits in a complicated fashion for the benefit of the one NUMA
> system. Just have the NUMA system not specify max_ram (so it gets
> the default of zero, ie "don't check") and have some NUMA-specific
> QEMUMachine fields which default to "system doesn't support NUMA".
> Then NUMA aware board models can do the right thing, and non-NUMA
> boards also do the right thing without having to think about
> NUMA-related fields at all.
> (Compare the way non-SMP boards don't have to worry about the
> max_cpus field.)
>
> -- PMM
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
2011-03-30 13:56 ` Anthony Liguori
@ 2011-03-30 14:07 ` Peter Maydell
2011-04-04 14:29 ` Jes Sorensen
0 siblings, 1 reply; 22+ messages in thread
From: Peter Maydell @ 2011-03-30 14:07 UTC (permalink / raw)
To: Anthony Liguori; +Cc: Blue Swirl, Jes Sorensen, qemu-devel, patches
On 30 March 2011 14:56, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 03/30/2011 08:22 AM, Peter Maydell wrote:
>> Not really, typically they're just filled up in some particular
>> order (main RAM in one place and expansion RAM elsewhere).
>> Since the board init function is only passed a single "ram_size"
>> parameter that's all you can do anyhow.
>
> FWIW, I don't think any static data is going to be perfect here. A lot of
> boards have strict requirements on ram_size based on plausible combinations
> of DIMMs. Arbitrary values up to ram_size is not good enough.
>
> ram_size ought to be viewed as a hint, not a mechanism to allow common code
> to completely validate the passed in ram size parameter. It's still up to
> the board to validate that the given ram size makes sense.
Yes, I agree, so we shouldn't try to specify some complicated
set of static data that still won't be good enough.
I'm trying to make it easy for boards to avoid crashing horribly
when the user passes a bad value; that's all.
-- PMM
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
2011-03-30 14:07 ` Peter Maydell
@ 2011-04-04 14:29 ` Jes Sorensen
2011-04-04 14:42 ` Peter Maydell
0 siblings, 1 reply; 22+ messages in thread
From: Jes Sorensen @ 2011-04-04 14:29 UTC (permalink / raw)
To: Peter Maydell; +Cc: Blue Swirl, qemu-devel, patches
On 03/30/11 16:07, Peter Maydell wrote:
> On 30 March 2011 14:56, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> On 03/30/2011 08:22 AM, Peter Maydell wrote:
>>> Not really, typically they're just filled up in some particular
>>> order (main RAM in one place and expansion RAM elsewhere).
>>> Since the board init function is only passed a single "ram_size"
>>> parameter that's all you can do anyhow.
>>
>> FWIW, I don't think any static data is going to be perfect here. A lot of
>> boards have strict requirements on ram_size based on plausible combinations
>> of DIMMs. Arbitrary values up to ram_size is not good enough.
>>
>> ram_size ought to be viewed as a hint, not a mechanism to allow common code
>> to completely validate the passed in ram size parameter. It's still up to
>> the board to validate that the given ram size makes sense.
>
> Yes, I agree, so we shouldn't try to specify some complicated
> set of static data that still won't be good enough.
>
> I'm trying to make it easy for boards to avoid crashing horribly
> when the user passes a bad value; that's all.
If you don't validate properly, is there really a point in introducing
that value anyway? From what you write, it sounds like it can still fail
for some limits of the memory valid if the config is wrong?
It still seems to me it would be better to have the boards present a
table of valid memory ranges so we can do a proper validation of the valud?
Cheers,
Jes
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
2011-04-04 14:29 ` Jes Sorensen
@ 2011-04-04 14:42 ` Peter Maydell
2011-04-04 14:53 ` Jes Sorensen
0 siblings, 1 reply; 22+ messages in thread
From: Peter Maydell @ 2011-04-04 14:42 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Blue Swirl, qemu-devel, patches
On 4 April 2011 15:29, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> On 03/30/11 16:07, Peter Maydell wrote:
>> On 30 March 2011 14:56, Anthony Liguori <anthony@codemonkey.ws> wrote:
>>> On 03/30/2011 08:22 AM, Peter Maydell wrote:
>>>> Not really, typically they're just filled up in some particular
>>>> order (main RAM in one place and expansion RAM elsewhere).
>>>> Since the board init function is only passed a single "ram_size"
>>>> parameter that's all you can do anyhow.
>>>
>>> FWIW, I don't think any static data is going to be perfect here. A lot of
>>> boards have strict requirements on ram_size based on plausible combinations
>>> of DIMMs. Arbitrary values up to ram_size is not good enough.
>>>
>>> ram_size ought to be viewed as a hint, not a mechanism to allow common code
>>> to completely validate the passed in ram size parameter. It's still up to
>>> the board to validate that the given ram size makes sense.
>>
>> Yes, I agree, so we shouldn't try to specify some complicated
>> set of static data that still won't be good enough.
>>
>> I'm trying to make it easy for boards to avoid crashing horribly
>> when the user passes a bad value; that's all.
>
> If you don't validate properly, is there really a point in introducing
> that value anyway? From what you write, it sounds like it can still fail
> for some limits of the memory valid if the config is wrong?
For the boards I care about (the ARM ones), the only validation
requirement is that we don't allow the user to specify so much
ram that we overlap physical RAM with I/O space. So ram_size is
good enough. For the sun4m boards we can assume that the only
validation they need is a ram_size check, because that's all they
do at the moment and nobody's complaining that I know of.
As far as I know Anthony is suggesting that some boards might in theory
have stricter memory size requirements. I agree that this is a possibility,
but if you have a rare board which has an idiosyncratic requirement then
the correct way to handle that is to add extra checks in the board init
functions. I don't see a huge queue of people with patches to add
complex checks to board init functions that would indicate that we need
a generic mechanism for handling this. What we do have is simple ram_size
limit checks (in sun4m and we need them for the arm devboards) -- which
is a demonstrated need that justifies the common code framework.
> It still seems to me it would be better to have the boards present a
> table of valid memory ranges so we can do a proper validation of the valud?
If you have a concrete example of multiple boards which we currently model
and which require this level of flexibility to avoid odd misbehaviour trying
to run a guest, then please point them out and I'll look at expanding the
patch to cover their requirements.
If this is just a theoretical issue, then I think we should only add the
extra generic framework code if and when we turn out to need it.
-- PMM
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
2011-04-04 14:42 ` Peter Maydell
@ 2011-04-04 14:53 ` Jes Sorensen
2011-04-04 16:54 ` Blue Swirl
2011-04-04 17:26 ` Peter Maydell
0 siblings, 2 replies; 22+ messages in thread
From: Jes Sorensen @ 2011-04-04 14:53 UTC (permalink / raw)
To: Peter Maydell; +Cc: Blue Swirl, qemu-devel, patches
On 04/04/11 16:42, Peter Maydell wrote:
> On 4 April 2011 15:29, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
>>> Yes, I agree, so we shouldn't try to specify some complicated
>>> set of static data that still won't be good enough.
>>>
>>> I'm trying to make it easy for boards to avoid crashing horribly
>>> when the user passes a bad value; that's all.
>>
>> If you don't validate properly, is there really a point in introducing
>> that value anyway? From what you write, it sounds like it can still fail
>> for some limits of the memory valid if the config is wrong?
>
> For the boards I care about (the ARM ones), the only validation
> requirement is that we don't allow the user to specify so much
> ram that we overlap physical RAM with I/O space. So ram_size is
> good enough. For the sun4m boards we can assume that the only
> validation they need is a ram_size check, because that's all they
> do at the moment and nobody's complaining that I know of.
I understand that what you are proposing seems to work well enough for
your problem at hand. What I am saying is that adding a mechanism like
that, can cause problems for adding a more generic mechanism that
handles more advanced boards in the future. I much prefer a generic
solution than a simple hack.
>> It still seems to me it would be better to have the boards present a
>> table of valid memory ranges so we can do a proper validation of the valud?
>
> If you have a concrete example of multiple boards which we currently model
> and which require this level of flexibility to avoid odd misbehaviour trying
> to run a guest, then please point them out and I'll look at expanding the
> patch to cover their requirements.
>
> If this is just a theoretical issue, then I think we should only add the
> extra generic framework code if and when we turn out to need it.
As I pointed out before, this is not a theoretical problem, most numa
systems have this issue, including many x86 boxes. I can see the problem
also existing with mips boards like the sb1250 ones I worked on many
years ago.
Having an a table of valid ram locations for a board, will also give you
a framework to validate against if you want to be able to specify chunks
of memory at different areas of a board. This could be useful for
testing behavior that is like it would be if you have a system where
installing different DIMMs would split the RAM up differently.
Jes
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
2011-04-04 14:53 ` Jes Sorensen
@ 2011-04-04 16:54 ` Blue Swirl
2011-04-12 13:58 ` Jes Sorensen
2011-04-04 17:26 ` Peter Maydell
1 sibling, 1 reply; 22+ messages in thread
From: Blue Swirl @ 2011-04-04 16:54 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Peter Maydell, qemu-devel, patches
On Mon, Apr 4, 2011 at 5:53 PM, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> On 04/04/11 16:42, Peter Maydell wrote:
>> On 4 April 2011 15:29, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
>>>> Yes, I agree, so we shouldn't try to specify some complicated
>>>> set of static data that still won't be good enough.
>>>>
>>>> I'm trying to make it easy for boards to avoid crashing horribly
>>>> when the user passes a bad value; that's all.
>>>
>>> If you don't validate properly, is there really a point in introducing
>>> that value anyway? From what you write, it sounds like it can still fail
>>> for some limits of the memory valid if the config is wrong?
>>
>> For the boards I care about (the ARM ones), the only validation
>> requirement is that we don't allow the user to specify so much
>> ram that we overlap physical RAM with I/O space. So ram_size is
>> good enough. For the sun4m boards we can assume that the only
>> validation they need is a ram_size check, because that's all they
>> do at the moment and nobody's complaining that I know of.
>
> I understand that what you are proposing seems to work well enough for
> your problem at hand. What I am saying is that adding a mechanism like
> that, can cause problems for adding a more generic mechanism that
> handles more advanced boards in the future. I much prefer a generic
> solution than a simple hack.
We could have "-device RAM,base=xxx,size=yyy,id=DIMM1 -numa
nodeid=zzz,memory=DIMM1" for fine tuned control.
But asking users to list and bind the DIMMs needed just to have some
amount of RAM is a bit too much. So we also need a simple case (-m)
and a simple check for the max memory.
It's still possible for the board to do additional checks and even use
heuristics to invent the DIMMs.
>>> It still seems to me it would be better to have the boards present a
>>> table of valid memory ranges so we can do a proper validation of the valud?
>>
>> If you have a concrete example of multiple boards which we currently model
>> and which require this level of flexibility to avoid odd misbehaviour trying
>> to run a guest, then please point them out and I'll look at expanding the
>> patch to cover their requirements.
>>
>> If this is just a theoretical issue, then I think we should only add the
>> extra generic framework code if and when we turn out to need it.
>
> As I pointed out before, this is not a theoretical problem, most numa
> systems have this issue, including many x86 boxes. I can see the problem
> also existing with mips boards like the sb1250 ones I worked on many
> years ago.
>
> Having an a table of valid ram locations for a board, will also give you
> a framework to validate against if you want to be able to specify chunks
> of memory at different areas of a board. This could be useful for
> testing behavior that is like it would be if you have a system where
> installing different DIMMs would split the RAM up differently.
Maybe we could remove some of memory logic in pc.c with this approach.
By the way, fw_cfg only uses one number for the memory size. This
should be changed. Alternatively the BIOSes could do a more realistic
RAM probe, but that would be wasteful.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
2011-04-04 16:54 ` Blue Swirl
@ 2011-04-12 13:58 ` Jes Sorensen
0 siblings, 0 replies; 22+ messages in thread
From: Jes Sorensen @ 2011-04-12 13:58 UTC (permalink / raw)
To: Blue Swirl; +Cc: Peter Maydell, qemu-devel, patches
On 04/04/11 18:54, Blue Swirl wrote:
> On Mon, Apr 4, 2011 at 5:53 PM, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
>> I understand that what you are proposing seems to work well enough for
>> your problem at hand. What I am saying is that adding a mechanism like
>> that, can cause problems for adding a more generic mechanism that
>> handles more advanced boards in the future. I much prefer a generic
>> solution than a simple hack.
>
> We could have "-device RAM,base=xxx,size=yyy,id=DIMM1 -numa
> nodeid=zzz,memory=DIMM1" for fine tuned control.
>
> But asking users to list and bind the DIMMs needed just to have some
> amount of RAM is a bit too much. So we also need a simple case (-m)
> and a simple check for the max memory.
I totally agree, but the suggestion I proposed earlier doesn't in any
way prevent this. If we use a table of valid memory locations for a
given board, then it is really easy for each board to provide a
validation function which accepts the amount or rejects it.
>> As I pointed out before, this is not a theoretical problem, most numa
>> systems have this issue, including many x86 boxes. I can see the problem
>> also existing with mips boards like the sb1250 ones I worked on many
>> years ago.
>>
>> Having an a table of valid ram locations for a board, will also give you
>> a framework to validate against if you want to be able to specify chunks
>> of memory at different areas of a board. This could be useful for
>> testing behavior that is like it would be if you have a system where
>> installing different DIMMs would split the RAM up differently.
>
> Maybe we could remove some of memory logic in pc.c with this approach.
I believe it would simplify things a great deal, and have the benefit
that we can emulate things much more realistically. The only issue is
that it takes a little more work up front, but it really isn't a big deal.
Cheers,
Jes
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
2011-04-04 14:53 ` Jes Sorensen
2011-04-04 16:54 ` Blue Swirl
@ 2011-04-04 17:26 ` Peter Maydell
2011-04-12 13:55 ` Jes Sorensen
1 sibling, 1 reply; 22+ messages in thread
From: Peter Maydell @ 2011-04-04 17:26 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Blue Swirl, qemu-devel, patches
On 4 April 2011 15:53, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> I understand that what you are proposing seems to work well enough for
> your problem at hand. What I am saying is that adding a mechanism like
> that, can cause problems for adding a more generic mechanism that
> handles more advanced boards in the future. I much prefer a generic
> solution than a simple hack.
I don't think it's a hack. I think it's a reasonably clean solution
to the set of cases we've actually encountered in practice, and I
think trying to design something more generalised without actually
having a use case to tie it to is just going to produce something
complicated which doesn't turn out to actually be what a hypothetical
"advanced board" will actually need. I think we're much better off
with code that does what we need it to do now, and designing
and implementing the complicated generic framework only when we
actually need it.
>> If you have a concrete example of multiple boards which we currently model
>> and which require this level of flexibility to avoid odd misbehaviour trying
>> to run a guest, then please point them out and I'll look at expanding the
>> patch to cover their requirements.
>>
>> If this is just a theoretical issue, then I think we should only add the
>> extra generic framework code if and when we turn out to need it.
>
> As I pointed out before, this is not a theoretical problem, most numa
> systems have this issue, including many x86 boxes. I can see the problem
> also existing with mips boards like the sb1250 ones I worked on many
> years ago.
OK, so presumably you can provide a qemu command line and an image
which demonstrates the problem...
> Having an a table of valid ram locations for a board
...I'm not sure this is even meaningful for boards where you can remap
the RAM to different physical addresses at runtime (versatile express
ought to do this although we don't currently model that bit).
-- PMM
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] [PATCH v3 0/7] Let boards state maximum RAM limits in QEMUMachine struct
2011-04-04 17:26 ` Peter Maydell
@ 2011-04-12 13:55 ` Jes Sorensen
0 siblings, 0 replies; 22+ messages in thread
From: Jes Sorensen @ 2011-04-12 13:55 UTC (permalink / raw)
To: Peter Maydell; +Cc: Blue Swirl, qemu-devel, patches
On 04/04/11 19:26, Peter Maydell wrote:
> On 4 April 2011 15:53, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
>> I understand that what you are proposing seems to work well enough for
>> your problem at hand. What I am saying is that adding a mechanism like
>> that, can cause problems for adding a more generic mechanism that
>> handles more advanced boards in the future. I much prefer a generic
>> solution than a simple hack.
>
> I don't think it's a hack. I think it's a reasonably clean solution
> to the set of cases we've actually encountered in practice, and I
> think trying to design something more generalised without actually
> having a use case to tie it to is just going to produce something
> complicated which doesn't turn out to actually be what a hypothetical
> "advanced board" will actually need. I think we're much better off
> with code that does what we need it to do now, and designing
> and implementing the complicated generic framework only when we
> actually need it.
Sorry but it is not a clean solution at all, it's a simple hack based on
a linear model, which happens to work in practice when dealing with some
simple boards. I suggested a very simple interface that would work fine
for embedded boards, and which would be simple to implement.
The so called advanced boards you're referring to are out there in
numbers already, you probably have a couple of them. They are called PCs.
>> As I pointed out before, this is not a theoretical problem, most numa
>> systems have this issue, including many x86 boxes. I can see the problem
>> also existing with mips boards like the sb1250 ones I worked on many
>> years ago.
>
> OK, so presumably you can provide a qemu command line and an image
> which demonstrates the problem...
Look at the -numa argument and show me the code that actually validates
the memory amount correctly in that case?
Jes
^ permalink raw reply [flat|nested] 22+ messages in thread