This minimizes QEMUMachine usage, as part of machine QOM-ification.
Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
QEMUMachine's fields are already in MachineClass. We can safely
make the switch because we copy them in machine_class_init() and
spapr_machine_class_init().
Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
In order to eliminate the QEMUMachine indirection,
add its fields directly to MachineClass.
Do not yet remove qemu_machine field because it is
still in use by sPAPR.
Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
[AF: Copied fields for sPAPR, too]
Signed-off-by: Andreas Färber <afaerber@suse.de>
This field shouldn't be used any more since we
adopted the QOM way of iterating over the types.
The commit that obsoleted it is:
commit 261747f176
vl: Use MachineClass instead of global QEMUMachine list
The machine registration flow is refactored to use the QOM functionality.
Instead of linking the machines into a list, each machine has a type
and the types can be traversed in the QOM way.
Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Machine rewriting added MACHINE() macro which is
already in use by other OpenBSD library.
Since qemu/sockets.h exposes the OpenBSD namespace,
the minimalistic approach is to add it as the first QEMU include.
Reported-by: Brad Smith <brad@comstyle.com>
Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
As reported in commit 9c06a1f79f, xen.h is
not self-contained with regards to its use of QEMUMachine. Fix this.
Reported-by: Alexander Graf <agraf@suse.de>
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
This reverts commit 9c06a1f79f.
The new header sysemu/qemumachine.h is undesired.
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
In order to allow attaching machine options to a machine instance,
current_machine is converted into MachineState.
As a first step of deprecating QEMUMachine, some of the functions
were modified to return MachineClass.
Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
The machine registration flow is refactored to use the QOM functionality.
Instead of linking the machines into a list, each machine has a type
and the types can be traversed in the QOM way.
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
The main functional change is to convert QEMUMachine into MachineClass
and QEMUMachineInitArgs into MachineState, instance of MachineClass.
As a first step, in order to make possible an incremental development,
both QEMUMachine and QEMUMachineInitArgs are being embedded into the
new types.
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Targets like ppc64 support different types of KVM, one which use
hypervisor mode and the other which doesn't. Add a new machine
option kvm-type that helps in selecting the respective ones
We also add a new QEMUMachine callback get_vm_type that helps
in mapping the string representation of kvm type specified.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
[agraf: spelling fixes, use error_report(), use qemumachine.h]
Signed-off-by: Alexander Graf <agraf@suse.de>
Older gcc versions (such as the one in SLES11) get confused when you declare
a typedef on the same struct twice.
To work around that limitation, let's extract the QEMUMachine typedef into a
separate header file that is guarded by preprocessor duplicate include checks.
This fixes the following type of compile errors for me:
In file included from vl.c:125:
include/hw/xen/xen.h:39: error: redefinition of typedef "QEMUMachine"
include/sysemu/kvm.h:155: error: previous declaration of "QEMUMachine" was here
Signed-off-by: Alexander Graf <agraf@suse.de>
Put it in QEMUMachineInitArgs, so I don't have to touch every board.
Reviewed-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
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>
Hook should be set by machines that implement CPU hot-add
via cpu-add QMP command.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Many of these should be cleaned up with proper qdev-/QOM-ification.
Right now there are many catch-all headers in include/hw/ARCH depending
on cpu.h, and this makes it necessary to compile these files per-target.
However, fixing this does not belong in these patches.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
