With all targets defining CPU_RESOLVING_TYPE, refactor
cpu_parse_cpu_model(type, cpu_model) to parse_cpu_model(cpu_model)
so that callers won't have to know internal resolving cpu
type. Place it in exec.c so it could be called from both
target independed vl.c and *-user/main.c.
That allows us to stop abusing cpu type from
MachineClass::default_cpu_type
as resolver class in vl.c which were confusing part of
cpu_parse_cpu_model().
Also with new parse_cpu_model(), the last users of cpu_init()
in null-machine.c and bsd/linux-user targets could be switched
to cpu_create() API and cpu_init() API will be removed by
follow up patch.
With no longer users left remove MachineState::cpu_model field,
new code should use MachineState::cpu_type instead and
leave cpu_model parsing to generic code in vl.c.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <1518000027-274608-5-git-send-email-imammedo@redhat.com>
[ehabkost: Fix bsd-user build error]
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
If the user currently tries to use the -kernel parameter, simply nothing
happens, and the user might get confused that there is nothing loaded
to memory, but also no error message has been issued. Since there is no
real generic way to load a kernel on all CPU types (but on some targets,
the generic loader can be used instead), issue an appropriate error
message here now to avoid the possible confusion.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1488271971-12624-1-git-send-email-thuth@redhat.com>
Reviewed-by: Marcel Apfelbaum <marcel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Sometimes it is useful to have just a machine with CPU and RAM, without
any further hardware in it, e.g. if you just want to do some instruction
debugging for TCG with a remote GDB attached to QEMU, or run some embedded
code with the "-semihosting" QEMU parameter. qemu-system-m68k already
features a "dummy" machine, and xtensa a "sim" machine for exactly this
purpose.
All target architectures have nowadays also a "none" machine, which would
be a perfect match for this, too - but it currently does not allow to add
CPU and RAM yet. Thus let's add these possibilities in a generic way to the
"none" machine, too, so that we hopefully do not need additional "dummy"
machines in the future anymore (and maybe can also get rid of the already
existing "dummy"/"sim" machines one day).
Note that the default behaviour of the "none" machine is not changed, i.e.
no CPU and no RAM is instantiated by default. You have explicitely got to
specify the CPU model with "-cpu" and the amount of RAM with "-m" to get
these new features.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1484743490-24721-1-git-send-email-thuth@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@xilinx.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Clean up includes so that osdep.h is included first and headers
which it implies are not included manually.
This commit was created with scripts/clean-includes.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1453832250-766-37-git-send-email-peter.maydell@linaro.org
Convert all machines to use DEFINE_MACHINE() instead of QEMUMachine
automatically using a script.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
[AF: Style cleanups, convert imx25_pdk machine]
Signed-off-by: Andreas Färber <afaerber@suse.de>
Total removal of QEMUMachineInitArgs struct. QEMUMachineInitArgs's fields
are copied into MachineState. Removed duplicated fields from MachineState.
All the other changes are only mechanical refactoring, no semantic changes.
Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> (s390)
Reviewed-by: Michael S. Tsirkin <mst@redhat.com> (PC)
[AF: Renamed ms -> machine, use MACHINE_GET_CLASS()]
Signed-off-by: Andreas Färber <afaerber@suse.de>
We set default boot order "cad" in every single machine definition
except "pseries" and "moxiesim", even though very few boards actually
care for boot order, and "cad" makes sense for even fewer.
Machines that care:
* pc and its variants
Accept up to three letters 'a', 'b' (undocumented alias for 'a'),
'c', 'd' and 'n'. Reject all others (fatal with -boot).
* nseries (n800, n810)
Check whether order starts with 'n'. Silently ignored otherwise.
* prep, g3beige, mac99
Extract the first character the machine understands (subset of
'a'..'f'). Silently ignored otherwise.
* spapr
Accept an arbitrary string (vl.c restricts it to contain only
'a'..'p', no duplicates).
* sun4[mdc]
Use the first character. Silently ignored otherwise.
Strip characters these machines ignore from their default boot order.
For all other machines, remove the unused default boot order
alltogether.
Note that my rename of QEMUMachine member boot_order to
default_boot_order and QEMUMachineInitArgs member boot_device to
boot_order has a welcome side effect: it makes every use of boot
orders visible in this patch, for easy review.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
