Re: [Qemu-devel] [PATCH v1 3/4] hw: Deduce the default machine from the specified CPU model
This changes the driver behavior to choose the default machine model based on the CPU being used. Defaulting the machine this way makes it easier to use QEMU as an ISS by just specifying the -cpu option since a default machine that is suitable for emulating the full ISA can be chosen. For example, currently on ARM the ARM Integrator/CP board is chosen as the default machine when specifying just a CPU. However, this doesn't work well when passing -cpu cortex-m3 since on ARMv7-M processors the NVIC is a part of the architecture and is needed to support instructions like SVC. Personally I'd rather we didn't support a default machine at all, at least for ARM. It does matter what board you run on, so you need to specify. A possible compromise is to only accept -cpu if -M is also specified. Just to pick an obvious example, you can't stick a core which supports VFPv4 (the A15 is the only one we have) into the integratorcp Yes you can. Your OS probably doesn't support it, and you might have trouble persuading the OS vendor to support something that doesn't physically exist, but those are a competely separate problems. We could reasonably add patches which made boards error out if you tried to use them with unsupported CPUs, I guess. That suffers from a large fuzzy region containing interesting combinations that could/do work, but will probably never be created in silicon. If done properly this the QOM conversion should give you this for free. Paul
Re: [Qemu-devel] [PATCH v1 3/4] hw: Deduce the default machine from the specified CPU model
On 28 August 2012 13:58, Paul Brook p...@codesourcery.com wrote: Peter Maydell wrote: Just to pick an obvious example, you can't stick a core which supports VFPv4 (the A15 is the only one we have) into the integratorcp Yes you can. No you can't. integratorcp.c doesn't create the parts of the CPU which live in QEMU's 'a15mpcore_priv' device, so the resulting mess is liable to just fall over. If anybody reports bugs in QEMU in such a configuration I will tell them to go away and use a supported configuration instead. At some point when we complete the QOM conversion the board will be instantiating a single object which has both the A15 cores and the builtin peripherals. However when that happens I would expect the QOM-objects for 926 and A15 not to be interchangeable, for the same reason that a physical h/w 926 and A15 aren't interchangeable -- they have different sets of connections to the outside world, and you can't just stuff one chip into a socket intended for the other. -- PMM
Re: [Qemu-devel] [PATCH v1 3/4] hw: Deduce the default machine from the specified CPU model
Just to pick an obvious example, you can't stick a core which supports VFPv4 (the A15 is the only one we have) into the integratorcp Yes you can. No you can't. integratorcp.c doesn't create the parts of the CPU which live in QEMU's 'a15mpcore_priv' device, so the resulting mess is liable to just fall over. If anybody reports bugs in QEMU in such a configuration I will tell them to go away and use a supported configuration instead. The A15 core itself will work just fine. The core is completely independent of the interrupt controller. Unlike the M profile cores where the NVIC is inherently part of the CPU exception handling mechanism. Paul
Re: [Qemu-devel] [PATCH v1 3/4] hw: Deduce the default machine from the specified CPU model
On 28 August 2012 14:32, Paul Brook p...@codesourcery.com wrote: No you can't. integratorcp.c doesn't create the parts of the CPU which live in QEMU's 'a15mpcore_priv' device, so the resulting mess is liable to just fall over. If anybody reports bugs in QEMU in such a configuration I will tell them to go away and use a supported configuration instead. The A15 core itself will work just fine. The core is completely independent of the interrupt controller. This is a view of the world which is becoming steadily less true. It is not possible to configure a hardware A9MP without the GIC and internal peripherals, for example. And the A15's timer peripherals are accessed as cp15 registers, not memory mapped I/O, making them even more obviously a coherent part of the CPU. -- PMM
[Qemu-devel] [PATCH v1 3/4] hw: Deduce the default machine from the specified CPU model
This changes the driver behavior to choose the default machine
model based on the CPU being used. Defaulting the machine this
way makes it easier to use QEMU as an ISS by just specifying
the -cpu option since a default machine that is suitable for
emulating the full ISA can be chosen.
For example, currently on ARM the ARM Integrator/CP board is
chosen as the default machine when specifying just a CPU.
However, this doesn't work well when passing -cpu cortex-m3
since on ARMv7-M processors the NVIC is a part of the architecture
and is needed to support instructions like SVC.
Signed-off-by: Meador Inge mead...@codesourcery.com
---
hw/alpha_dp264.c |2 +-
hw/axis_dev88.c |2 +-
hw/boards.h |4 ++--
hw/integratorcp.c |2 +-
hw/lm32_boards.c |3 +--
hw/mcf5208.c |2 +-
hw/milkymist.c|1 -
hw/mips_malta.c |2 +-
hw/openrisc_sim.c |2 +-
hw/pc_piix.c |2 +-
hw/pc_sysfw.c |2 +-
hw/petalogix_ml605_mmu.c |1 -
hw/petalogix_s3adsp1800_mmu.c |2 +-
hw/ppc_newworld.c |2 +-
hw/ppc_oldworld.c |2 +-
hw/puv3.c |2 +-
hw/s390-virtio.c |2 +-
hw/shix.c |2 +-
hw/sun4m.c|2 +-
hw/sun4u.c|2 +-
hw/xtensa_sim.c |2 +-
qapi-schema.json |4 ++--
vl.c | 38 +-
23 files changed, 47 insertions(+), 38 deletions(-)
diff --git a/hw/alpha_dp264.c b/hw/alpha_dp264.c
index 9eb939f..d6717aa 100644
--- a/hw/alpha_dp264.c
+++ b/hw/alpha_dp264.c
@@ -169,7 +169,7 @@ static QEMUMachine clipper_machine = {
.desc = Alpha DP264/CLIPPER,
.init = clipper_init,
.max_cpus = 4,
-.is_default = 1,
+.default_for_cpu_model = any,
};
static void clipper_machine_init(void)
diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c
index eab6327..41078e6 100644
--- a/hw/axis_dev88.c
+++ b/hw/axis_dev88.c
@@ -353,7 +353,7 @@ static QEMUMachine axisdev88_machine = {
.name = axis-dev88,
.desc = AXIS devboard 88,
.init = axisdev88_init,
-.is_default = 1,
+.default_for_cpu_model = any,
};
static void axisdev88_machine_init(void)
diff --git a/hw/boards.h b/hw/boards.h
index a2e0a54..6f52561 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -28,7 +28,7 @@ typedef struct QEMUMachine {
no_floppy:1,
no_cdrom:1,
no_sdcard:1;
-int is_default;
+const char* default_for_cpu_model;
const char *default_machine_opts;
GlobalProperty *compat_props;
struct QEMUMachine *next;
@@ -36,7 +36,7 @@ typedef struct QEMUMachine {
} QEMUMachine;
int qemu_register_machine(QEMUMachine *m);
-QEMUMachine *find_default_machine(void);
+QEMUMachine *find_default_machine(const char *cpu_model);
extern QEMUMachine *current_machine;
diff --git a/hw/integratorcp.c b/hw/integratorcp.c
index d0e2e90..4df0774 100644
--- a/hw/integratorcp.c
+++ b/hw/integratorcp.c
@@ -509,7 +509,7 @@ static QEMUMachine integratorcp_machine = {
.name = integratorcp,
.desc = ARM Integrator/CP (ARM926EJ-S),
.init = integratorcp_init,
-.is_default = 1,
+.default_for_cpu_model = any,
};
static void integratorcp_machine_init(void)
diff --git a/hw/lm32_boards.c b/hw/lm32_boards.c
index b76d800..2e5348b 100644
--- a/hw/lm32_boards.c
+++ b/hw/lm32_boards.c
@@ -290,14 +290,13 @@ static QEMUMachine lm32_evr_machine = {
.name = lm32-evr,
.desc = LatticeMico32 EVR32 eval system,
.init = lm32_evr_init,
-.is_default = 1
+.default_for_cpu_model = any,
};
static QEMUMachine lm32_uclinux_machine = {
.name = lm32-uclinux,
.desc = lm32 platform for uClinux and u-boot by Theobroma Systems,
.init = lm32_uclinux_init,
-.is_default = 0
};
static void lm32_machine_init(void)
diff --git a/hw/mcf5208.c b/hw/mcf5208.c
index ee25b1b..0e28ffd9 100644
--- a/hw/mcf5208.c
+++ b/hw/mcf5208.c
@@ -291,7 +291,7 @@ static QEMUMachine mcf5208evb_machine = {
.name = mcf5208evb,
.desc = MCF5206EVB,
.init = mcf5208evb_init,
-.is_default = 1,
+.default_for_cpu_model = any,
};
static void mcf5208evb_machine_init(void)
diff --git a/hw/milkymist.c b/hw/milkymist.c
index 2e7235b..a8606ea 100644
--- a/hw/milkymist.c
+++ b/hw/milkymist.c
@@ -207,7 +207,6 @@ static QEMUMachine milkymist_machine = {
.name = milkymist,
.desc = Milkymist One,
.init = milkymist_init,
-.is_default = 0
};
static void milkymist_machine_init(void)
diff --git a/hw/mips_malta.c b/hw/mips_malta.c
index ad23f26..ac955e9 100644
--- a/hw/mips_malta.c
+++ b/hw/mips_malta.c
@@ -1020,7 +1020,7 @@ static QEMUMachine mips_malta_machine = {
.desc = MIPS Malta Core LV,
.init = mips_malta_init,
.max_cpus = 16,
-
Re: [Qemu-devel] [PATCH v1 3/4] hw: Deduce the default machine from the specified CPU model
On 27 August 2012 21:37, Meador Inge mead...@codesourcery.com wrote: This changes the driver behavior to choose the default machine model based on the CPU being used. Defaulting the machine this way makes it easier to use QEMU as an ISS by just specifying the -cpu option since a default machine that is suitable for emulating the full ISA can be chosen. For example, currently on ARM the ARM Integrator/CP board is chosen as the default machine when specifying just a CPU. However, this doesn't work well when passing -cpu cortex-m3 since on ARMv7-M processors the NVIC is a part of the architecture and is needed to support instructions like SVC. Personally I'd rather we didn't support a default machine at all, at least for ARM. It does matter what board you run on, so you need to specify. Just to pick an obvious example, you can't stick a core which supports VFPv4 (the A15 is the only one we have) into the integratorcp, so you would still have to specify both a CPU and a machine name there. We could reasonably add patches which made boards error out if you tried to use them with unsupported CPUs, I guess. -- PMM
