2007-11-17 18:14:51 +01:00
|
|
|
#ifndef SYSEMU_H
|
|
|
|
|
#define SYSEMU_H
|
|
|
|
|
/* Misc. things related to the system emulator. */
|
|
|
|
|
|
2018-02-11 10:36:01 +01:00
|
|
|
#include "qapi/qapi-types-run-state.h"
|
2012-12-17 18:20:00 +01:00
|
|
|
#include "qemu/timer.h"
|
|
|
|
|
#include "qemu/notify.h"
|
|
|
|
|
#include "qemu/main-loop.h"
|
2014-05-14 11:43:07 +02:00
|
|
|
#include "qemu/bitmap.h"
|
2016-09-21 06:27:22 +02:00
|
|
|
#include "qemu/uuid.h"
|
2014-05-14 11:43:15 +02:00
|
|
|
#include "qom/object.h"
|
2009-03-06 00:01:23 +01:00
|
|
|
|
2007-11-17 18:14:51 +01:00
|
|
|
/* vl.c */
|
2011-07-29 19:26:33 +02:00
|
|
|
|
2007-11-17 18:14:51 +01:00
|
|
|
extern const char *bios_name;
|
Revert "migration: move only_migratable to MigrationState"
This reverts commit 3df663e575f1876d7f3bc684f80e72fca0703d39.
This reverts commit b605c47b57b58e61a901a50a0762dccf43d94783.
Command line option --only-migratable is for disallowing any
configuration that can block migration.
Initially, --only-migratable set global variable @only_migratable.
Commit 3df663e575 "migration: move only_migratable to MigrationState"
replaced it by MigrationState member @only_migratable. That was a
mistake.
First, it doesn't make sense on the design level. MigrationState
captures the state of an individual migration, but --only-migratable
isn't a property of an individual migration, it's a restriction on
QEMU configuration. With fault tolerance, we could have several
migrations at once. --only-migratable would certainly protect all of
them. Storing it in MigrationState feels inappropriate.
Second, it contributes to a dependency cycle that manifests itself as
a bug now.
Putting @only_migratable into MigrationState means its available only
after migration_object_init().
We can't set it before migration_object_init(), so we delay setting it
with a global property (this is fixup commit b605c47b57 "migration:
fix handling for --only-migratable").
We can't get it before migration_object_init(), so anything that uses
it can only run afterwards.
Since migrate_add_blocker() needs to obey --only-migratable, any code
adding migration blockers can run only afterwards. This contributes
to the following dependency cycle:
* configure_blockdev() must run before machine_set_property()
so machine properties can refer to block backends
* machine_set_property() before configure_accelerator()
so machine properties like kvm-irqchip get applied
* configure_accelerator() before migration_object_init()
so that Xen's accelerator compat properties get applied.
* migration_object_init() before configure_blockdev()
so configure_blockdev() can add migration blockers
The cycle was closed when recent commit cda4aa9a5a0 "Create block
backends before setting machine properties" added the first
dependency, and satisfied it by violating the last one. Broke block
backends that add migration blockers.
Moving @only_migratable into MigrationState was a mistake. Revert it.
This doesn't quite break the "migration_object_init() before
configure_blockdev() dependency, since migrate_add_blocker() still has
another dependency on migration_object_init(). To be addressed the
next commit.
Note that the reverted commit made -only-migratable sugar for -global
migration.only-migratable=on below the hood. Documentation has only
ever mentioned -only-migratable. This commit removes the arcane &
undocumented alternative to -only-migratable again. Nobody should be
using it.
Conflicts:
include/migration/misc.h
migration/migration.c
migration/migration.h
vl.c
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190401090827.20793-3-armbru@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2019-04-01 11:08:24 +02:00
|
|
|
extern int only_migratable;
|
2007-11-17 18:14:51 +01:00
|
|
|
extern const char *qemu_name;
|
2016-09-21 06:27:22 +02:00
|
|
|
extern QemuUUID qemu_uuid;
|
smbios: Make multiple -smbios type= accumulate sanely
Currently, -smbios type=T,NAME=VAL,... adds one field (T,NAME) with
value VAL to fw_cfg for each unique NAME. If NAME occurs multiple
times, the last one's VAL is used (before the QemuOpts conversion, the
first one was used).
Multiple -smbios can add multiple fields with the same (T, NAME).
SeaBIOS reads all of them from fw_cfg, but uses only the first field
(T, NAME). The others are ignored.
"First one wins, subsequent ones get ignored silently" isn't nice. We
commonly let the last option win. Useful, because it lets you
-readconfig first, then selectively override with command line
options.
Clean up -smbios to work the common way. Accumulate the settings,
with later ones overwriting earlier ones. Put the result into fw_cfg
(no more useless duplicates).
Bonus cleanup: qemu_uuid_parse() no longer sets SMBIOS system uuid by
side effect.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-08-16 15:18:31 +02:00
|
|
|
extern bool qemu_uuid_set;
|
2007-11-17 18:14:51 +01:00
|
|
|
|
2011-07-29 20:04:45 +02:00
|
|
|
bool runstate_check(RunState state);
|
|
|
|
|
void runstate_set(RunState new_state);
|
2011-07-29 20:36:43 +02:00
|
|
|
int runstate_is_running(void);
|
2013-04-26 05:24:40 +02:00
|
|
|
bool runstate_needs_reset(void);
|
2014-10-08 11:53:22 +02:00
|
|
|
bool runstate_store(char *str, size_t size);
|
2007-11-17 18:14:51 +01:00
|
|
|
typedef struct vm_change_state_entry VMChangeStateEntry;
|
2011-07-29 19:26:33 +02:00
|
|
|
typedef void VMChangeStateHandler(void *opaque, int running, RunState state);
|
2007-11-17 18:14:51 +01:00
|
|
|
|
|
|
|
|
VMChangeStateEntry *qemu_add_vm_change_state_handler(VMChangeStateHandler *cb,
|
|
|
|
|
void *opaque);
|
2019-06-20 19:37:07 +02:00
|
|
|
VMChangeStateEntry *qemu_add_vm_change_state_handler_prio(
|
|
|
|
|
VMChangeStateHandler *cb, void *opaque, int priority);
|
2007-11-17 18:14:51 +01:00
|
|
|
void qemu_del_vm_change_state_handler(VMChangeStateEntry *e);
|
2011-07-29 19:26:33 +02:00
|
|
|
void vm_state_notify(int running, RunState state);
|
2011-02-09 16:29:40 +01:00
|
|
|
|
shutdown: Expose bool cause in SHUTDOWN and RESET events
Libvirt would like to be able to distinguish between a SHUTDOWN
event triggered solely by guest request and one triggered by a
SIGTERM or other action on the host. While qemu_kill_report() was
already able to give different output to stderr based on whether a
shutdown was triggered by a host signal (but NOT by a host UI event,
such as clicking the X on the window), that information was then
lost to management. The previous patches improved things to use an
enum throughout all callsites, so now we have something ready to
expose through QMP.
Note that for now, the decision was to expose ONLY a boolean,
rather than promoting ShutdownCause to a QAPI enum; this is because
libvirt has not expressed an interest in anything finer-grained.
We can still add additional details, in a backwards-compatible
manner, if a need later arises (if the addition happens before 2.10,
we can replace the bool with an enum; otherwise, the enum will have
to be in addition to the bool); this patch merely adds a helper
shutdown_caused_by_guest() to map the internal enum into the
external boolean.
Update expected iotest outputs to match the new data (complete
coverage of the affected tests is obtained by -raw, -qcow2, and -nbd).
Here is output from 'virsh qemu-monitor-event --loop' with the
patch installed:
event SHUTDOWN at 1492639680.731251 for domain fedora_13: {"guest":true}
event STOP at 1492639680.732116 for domain fedora_13: <null>
event SHUTDOWN at 1492639680.732830 for domain fedora_13: {"guest":false}
Note that libvirt runs qemu with -no-shutdown: the first SHUTDOWN event
was triggered by an action I took directly in the guest (shutdown -h),
at which point qemu stops the vcpus and waits for libvirt to do any
final cleanups; the second SHUTDOWN event is the result of libvirt
sending SIGTERM now that it has completed cleanup. Libvirt is already
smart enough to only feed the first qemu SHUTDOWN event to the end user
(remember, virsh qemu-monitor-event is a low-level debugging interface
that is explicitly unsupported by libvirt, so it sees things that normal
end users do not); changing qemu to emit SHUTDOWN only once is outside
the scope of this series.
See also https://bugzilla.redhat.com/1384007
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20170515214114.15442-6-eblake@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2017-05-15 23:41:14 +02:00
|
|
|
static inline bool shutdown_caused_by_guest(ShutdownCause cause)
|
|
|
|
|
{
|
|
|
|
|
return cause >= SHUTDOWN_CAUSE_GUEST_SHUTDOWN;
|
|
|
|
|
}
|
2011-06-14 18:29:43 +02:00
|
|
|
|
2007-11-17 18:14:51 +01:00
|
|
|
void vm_start(void);
|
2017-02-14 18:07:47 +01:00
|
|
|
int vm_prepare_start(void);
|
2013-07-05 13:49:54 +02:00
|
|
|
int vm_stop(RunState state);
|
|
|
|
|
int vm_stop_force_state(RunState state);
|
2018-03-07 15:42:05 +01:00
|
|
|
int vm_shutdown(void);
|
2007-11-17 18:14:51 +01:00
|
|
|
|
2012-02-23 13:45:19 +01:00
|
|
|
typedef enum WakeupReason {
|
2013-09-25 18:38:29 +02:00
|
|
|
/* Always keep QEMU_WAKEUP_REASON_NONE = 0 */
|
|
|
|
|
QEMU_WAKEUP_REASON_NONE = 0,
|
2012-02-23 13:45:24 +01:00
|
|
|
QEMU_WAKEUP_REASON_RTC,
|
2012-02-23 13:45:25 +01:00
|
|
|
QEMU_WAKEUP_REASON_PMTIMER,
|
2013-09-25 18:38:29 +02:00
|
|
|
QEMU_WAKEUP_REASON_OTHER,
|
2012-02-23 13:45:19 +01:00
|
|
|
} WakeupReason;
|
|
|
|
|
|
2018-05-11 19:24:43 +02:00
|
|
|
void qemu_exit_preconfig_request(void);
|
2017-05-15 23:41:13 +02:00
|
|
|
void qemu_system_reset_request(ShutdownCause reason);
|
2012-02-23 13:45:19 +01:00
|
|
|
void qemu_system_suspend_request(void);
|
|
|
|
|
void qemu_register_suspend_notifier(Notifier *notifier);
|
qmp hmp: Make system_wakeup check wake-up support and run state
The qmp/hmp command 'system_wakeup' is simply a direct call to
'qemu_system_wakeup_request' from vl.c. This function verifies if
runstate is SUSPENDED and if the wake up reason is valid before
proceeding. However, no error or warning is thrown if any of those
pre-requirements isn't met. There is no way for the caller to
differentiate between a successful wakeup or an error state caused
when trying to wake up a guest that wasn't suspended.
This means that system_wakeup is silently failing, which can be
considered a bug. Adding error handling isn't an API break in this
case - applications that didn't check the result will remain broken,
the ones that check it will have a chance to deal with it.
Adding to that, the commit before previous created a new QMP API called
query-current-machine, with a new flag called wakeup-suspend-support,
that indicates if the guest has the capability of waking up from suspended
state. Although such guest will never reach SUSPENDED state and erroring
it out in this scenario would suffice, it is more informative for the user
to differentiate between a failure because the guest isn't suspended versus
a failure because the guest does not have support for wake up at all.
All this considered, this patch changes qmp_system_wakeup to check if
the guest is capable of waking up from suspend, and if it is suspended.
After this patch, this is the output of system_wakeup in a guest that
does not have wake-up from suspend support (ppc64):
(qemu) system_wakeup
wake-up from suspend is not supported by this guest
(qemu)
And this is the output of system_wakeup in a x86 guest that has the
support but isn't suspended:
(qemu) system_wakeup
Unable to wake up: guest is not in suspended state
(qemu)
Reported-by: Balamuruhan S <bala24@linux.vnet.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20181205194701.17836-4-danielhb413@gmail.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Acked-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-05 20:47:01 +01:00
|
|
|
bool qemu_wakeup_suspend_enabled(void);
|
|
|
|
|
void qemu_system_wakeup_request(WakeupReason reason, Error **errp);
|
2012-02-23 13:45:19 +01:00
|
|
|
void qemu_system_wakeup_enable(WakeupReason reason, bool enabled);
|
|
|
|
|
void qemu_register_wakeup_notifier(Notifier *notifier);
|
qmp: query-current-machine with wakeup-suspend-support
When issuing the qmp/hmp 'system_wakeup' command, what happens in a
nutshell is:
- qmp_system_wakeup_request set runstate to RUNNING, sets a wakeup_reason
and notify the event
- in the main_loop, all vcpus are paused, a system reset is issued, all
subscribers of wakeup_notifiers receives a notification, vcpus are then
resumed and the wake up QAPI event is fired
Note that this procedure alone doesn't ensure that the guest will awake
from SUSPENDED state - the subscribers of the wake up event must take
action to resume the guest, otherwise the guest will simply reboot. At
this moment, only the ACPI machines via acpi_pm1_cnt_init and xen_hvm_init
have wake-up from suspend support.
However, only the presence of 'system_wakeup' is required for QGA to
support 'guest-suspend-ram' and 'guest-suspend-hybrid' at this moment.
This means that the user/management will expect to suspend the guest using
one of those suspend commands and then resume execution using system_wakeup,
regardless of the support offered in system_wakeup in the first place.
This patch creates a new API called query-current-machine [1], that holds
a new flag called 'wakeup-suspend-support' that indicates if the guest
supports wake up from suspend via system_wakeup. The machine is considered
to implement wake-up support if a call to a new 'qemu_register_wakeup_support'
is made during its init, as it is now being done inside acpi_pm1_cnt_init
and xen_hvm_init. This allows for any other machine type to declare wake-up
support regardless of ACPI state or wakeup_notifiers subscription, making easier
for newer implementations that might have their own mechanisms in the future.
This is the expected output of query-current-machine when running a x86
guest:
{"execute" : "query-current-machine"}
{"return": {"wakeup-suspend-support": true}}
Running the same x86 guest, but with the --no-acpi option:
{"execute" : "query-current-machine"}
{"return": {"wakeup-suspend-support": false}}
This is the output when running a pseries guest:
{"execute" : "query-current-machine"}
{"return": {"wakeup-suspend-support": false}}
With this extra tool, management can avoid situations where a guest
that does not have proper suspend/wake capabilities ends up in
inconsistent state (e.g.
https://github.com/open-power-host-os/qemu/issues/31).
[1] the decision of creating the query-current-machine API is based
on discussions in the QEMU mailing list where it was decided that
query-target wasn't a proper place to store the wake-up flag, neither
was query-machines because this isn't a static property of the
machine object. This new API can then be used to store other
dynamic machine properties that are scattered around the code
ATM. More info at:
https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg04235.html
Reported-by: Balamuruhan S <bala24@linux.vnet.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20181205194701.17836-2-danielhb413@gmail.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Acked-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2018-12-05 20:46:59 +01:00
|
|
|
void qemu_register_wakeup_support(void);
|
2017-05-15 23:41:13 +02:00
|
|
|
void qemu_system_shutdown_request(ShutdownCause reason);
|
2007-11-17 18:14:51 +01:00
|
|
|
void qemu_system_powerdown_request(void);
|
2012-09-05 23:06:21 +02:00
|
|
|
void qemu_register_powerdown_notifier(Notifier *notifier);
|
2018-12-21 15:40:33 +01:00
|
|
|
void qemu_register_shutdown_notifier(Notifier *notifier);
|
2011-02-07 12:19:16 +01:00
|
|
|
void qemu_system_debug_request(void);
|
2011-07-29 19:26:33 +02:00
|
|
|
void qemu_system_vmstop_request(RunState reason);
|
2014-06-05 14:53:58 +02:00
|
|
|
void qemu_system_vmstop_request_prepare(void);
|
2017-02-14 18:07:47 +01:00
|
|
|
bool qemu_vmstop_requested(RunState *r);
|
shutdown: Prepare for use of an enum in reset/shutdown_request
We want to track why a guest was shutdown; in particular, being able
to tell the difference between a guest request (such as ACPI request)
and host request (such as SIGINT) will prove useful to libvirt.
Since all requests eventually end up changing shutdown_requested in
vl.c, the logical change is to make that value track the reason,
rather than its current 0/1 contents.
Since command-line options control whether a reset request is turned
into a shutdown request instead, the same treatment is given to
reset_requested.
This patch adds an internal enum ShutdownCause that describes reasons
that a shutdown can be requested, and changes qemu_system_reset() to
pass the reason through, although for now nothing is actually changed
with regards to what gets reported. The enum could be exported via
QAPI at a later date, if deemed necessary, but for now, there has not
been a request to expose that much detail to end clients.
For the most part, we turn 0 into SHUTDOWN_CAUSE_NONE, and 1 into
SHUTDOWN_CAUSE_HOST_ERROR; the only specific case where we have enough
information right now to use a different value is when we are reacting
to a host signal. It will take a further patch to edit all call-sites
that can trigger a reset or shutdown request to properly pass in any
other reasons; this patch includes TODOs to point such places out.
qemu_system_reset() trades its 'bool report' parameter for a
'ShutdownCause reason', with all non-zero values having the same
effect; this lets us get rid of the weird #defines for VMRESET_*
as synonyms for bools.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20170515214114.15442-3-eblake@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2017-05-15 23:41:11 +02:00
|
|
|
ShutdownCause qemu_shutdown_requested_get(void);
|
|
|
|
|
ShutdownCause qemu_reset_requested_get(void);
|
2011-03-15 12:56:04 +01:00
|
|
|
void qemu_system_killed(int signal, pid_t pid);
|
shutdown: Prepare for use of an enum in reset/shutdown_request
We want to track why a guest was shutdown; in particular, being able
to tell the difference between a guest request (such as ACPI request)
and host request (such as SIGINT) will prove useful to libvirt.
Since all requests eventually end up changing shutdown_requested in
vl.c, the logical change is to make that value track the reason,
rather than its current 0/1 contents.
Since command-line options control whether a reset request is turned
into a shutdown request instead, the same treatment is given to
reset_requested.
This patch adds an internal enum ShutdownCause that describes reasons
that a shutdown can be requested, and changes qemu_system_reset() to
pass the reason through, although for now nothing is actually changed
with regards to what gets reported. The enum could be exported via
QAPI at a later date, if deemed necessary, but for now, there has not
been a request to expose that much detail to end clients.
For the most part, we turn 0 into SHUTDOWN_CAUSE_NONE, and 1 into
SHUTDOWN_CAUSE_HOST_ERROR; the only specific case where we have enough
information right now to use a different value is when we are reacting
to a host signal. It will take a further patch to edit all call-sites
that can trigger a reset or shutdown request to properly pass in any
other reasons; this patch includes TODOs to point such places out.
qemu_system_reset() trades its 'bool report' parameter for a
'ShutdownCause reason', with all non-zero values having the same
effect; this lets us get rid of the weird #defines for VMRESET_*
as synonyms for bools.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20170515214114.15442-3-eblake@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2017-05-15 23:41:11 +02:00
|
|
|
void qemu_system_reset(ShutdownCause reason);
|
2017-02-14 07:25:23 +01:00
|
|
|
void qemu_system_guest_panicked(GuestPanicInformation *info);
|
2007-11-17 18:14:51 +01:00
|
|
|
|
2010-06-04 14:08:07 +02:00
|
|
|
void qemu_add_exit_notifier(Notifier *notify);
|
|
|
|
|
void qemu_remove_exit_notifier(Notifier *notify);
|
|
|
|
|
|
2018-03-06 06:33:12 +01:00
|
|
|
extern bool machine_init_done;
|
|
|
|
|
|
2010-12-08 12:35:08 +01:00
|
|
|
void qemu_add_machine_init_done_notifier(Notifier *notify);
|
2016-06-27 17:38:32 +02:00
|
|
|
void qemu_remove_machine_init_done_notifier(Notifier *notify);
|
2010-12-08 12:35:08 +01:00
|
|
|
|
2009-07-27 23:17:51 +02:00
|
|
|
extern int autostart;
|
2009-07-30 12:15:02 +02:00
|
|
|
|
|
|
|
|
typedef enum {
|
2010-04-27 11:50:11 +02:00
|
|
|
VGA_NONE, VGA_STD, VGA_CIRRUS, VGA_VMWARE, VGA_XENFB, VGA_QXL,
|
2014-09-10 14:28:48 +02:00
|
|
|
VGA_TCX, VGA_CG3, VGA_DEVICE, VGA_VIRTIO,
|
2015-10-28 22:19:58 +01:00
|
|
|
VGA_TYPE_MAX,
|
2009-07-30 12:15:02 +02:00
|
|
|
} VGAInterfaceType;
|
|
|
|
|
|
|
|
|
|
extern int vga_interface_type;
|
|
|
|
|
#define xenfb_enabled (vga_interface_type == VGA_XENFB)
|
|
|
|
|
|
2007-11-17 18:14:51 +01:00
|
|
|
extern int graphic_width;
|
|
|
|
|
extern int graphic_height;
|
|
|
|
|
extern int graphic_depth;
|
2014-11-20 09:49:44 +01:00
|
|
|
extern int display_opengl;
|
2007-11-17 18:14:51 +01:00
|
|
|
extern const char *keyboard_layout;
|
|
|
|
|
extern int win2k_install_hack;
|
|
|
|
|
extern int alt_grab;
|
2009-09-17 22:48:04 +02:00
|
|
|
extern int ctrl_grab;
|
2007-11-17 18:14:51 +01:00
|
|
|
extern int smp_cpus;
|
vl: exit if maxcpus is negative
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---Steps to Reproduce---
When passed a negative number to 'maxcpus' parameter, Qemu aborts
with a core dump.
Run the following command with maxcpus argument as negative number
ppc64-softmmu/qemu-system-ppc64 --nographic -vga none -machine
pseries,accel=kvm,kvm-type=HV -m size=200g -device virtio-blk-pci,
drive=rootdisk -drive file=/home/images/pegas-1.0-ppc64le.qcow2,
if=none,cache=none,id=rootdisk,format=qcow2 -monitor telnet
:127.0.0.1:1234,server,nowait -net nic,model=virtio -net
user -redir tcp:2000::22 -device nec-usb-xhci -smp 8,cores=1,
threads=1,maxcpus=-12
(process:12149): GLib-ERROR **: gmem.c:130: failed to allocate
18446744073709550568 bytes
Trace/breakpoint trap
Reported-by: R.Nageswara Sastry <rnsastry@linux.vnet.ibm.com>
Signed-off-by: Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
Message-Id: <1504511031-26834-1-git-send-email-s1seetee@linux.vnet.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2017-09-04 09:43:51 +02:00
|
|
|
extern unsigned int max_cpus;
|
2007-11-17 18:14:51 +01:00
|
|
|
extern int cursor_hide;
|
|
|
|
|
extern int graphic_rotate;
|
|
|
|
|
extern int no_quit;
|
2010-05-11 23:07:04 +02:00
|
|
|
extern int no_shutdown;
|
2007-11-17 18:14:51 +01:00
|
|
|
extern int old_param;
|
2009-07-02 00:19:02 +02:00
|
|
|
extern int boot_menu;
|
2014-10-07 10:00:05 +02:00
|
|
|
extern bool boot_strict;
|
2011-07-27 12:04:55 +02:00
|
|
|
extern uint8_t *boot_splash_filedata;
|
2015-11-05 19:11:22 +01:00
|
|
|
extern bool enable_mlock;
|
2018-06-22 21:22:05 +02:00
|
|
|
extern bool enable_cpu_pm;
|
2013-08-21 17:03:04 +02:00
|
|
|
extern QEMUClockType rtc_clock;
|
2014-05-14 11:43:18 +02:00
|
|
|
extern const char *mem_path;
|
|
|
|
|
extern int mem_prealloc;
|
2007-11-17 18:14:51 +01:00
|
|
|
|
2014-05-14 11:43:09 +02:00
|
|
|
#define MAX_NODES 128
|
2015-06-02 13:23:09 +02:00
|
|
|
#define NUMA_NODE_UNASSIGNED MAX_NODES
|
numa: Allow setting NUMA distance for different NUMA nodes
This patch is going to add SLIT table support in QEMU, and provides
additional option `dist` for command `-numa` to allow user set vNUMA
distance by QEMU command.
With this patch, when a user wants to create a guest that contains
several vNUMA nodes and also wants to set distance among those nodes,
the QEMU command would like:
```
-numa node,nodeid=0,cpus=0 \
-numa node,nodeid=1,cpus=1 \
-numa node,nodeid=2,cpus=2 \
-numa node,nodeid=3,cpus=3 \
-numa dist,src=0,dst=1,val=21 \
-numa dist,src=0,dst=2,val=31 \
-numa dist,src=0,dst=3,val=41 \
-numa dist,src=1,dst=2,val=21 \
-numa dist,src=1,dst=3,val=31 \
-numa dist,src=2,dst=3,val=21 \
```
Signed-off-by: He Chen <he.chen@linux.intel.com>
Message-Id: <1493260558-20728-1-git-send-email-he.chen@linux.intel.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-04-27 04:35:58 +02:00
|
|
|
#define NUMA_DISTANCE_MIN 10
|
|
|
|
|
#define NUMA_DISTANCE_DEFAULT 20
|
|
|
|
|
#define NUMA_DISTANCE_MAX 254
|
|
|
|
|
#define NUMA_DISTANCE_UNREACHABLE 255
|
2014-03-18 20:29:23 +01:00
|
|
|
|
2007-11-17 18:14:51 +01:00
|
|
|
#define MAX_OPTION_ROMS 16
|
2010-12-08 12:35:07 +01:00
|
|
|
typedef struct QEMUOptionRom {
|
|
|
|
|
const char *name;
|
|
|
|
|
int32_t bootindex;
|
|
|
|
|
} QEMUOptionRom;
|
|
|
|
|
extern QEMUOptionRom option_rom[MAX_OPTION_ROMS];
|
2007-11-17 18:14:51 +01:00
|
|
|
extern int nb_option_roms;
|
|
|
|
|
|
|
|
|
|
#define MAX_PROM_ENVS 128
|
|
|
|
|
extern const char *prom_envs[MAX_PROM_ENVS];
|
|
|
|
|
extern unsigned int nb_prom_envs;
|
|
|
|
|
|
2010-08-23 23:43:10 +02:00
|
|
|
/* generic hotplug */
|
hmp: Name HMP command handler functions hmp_COMMAND()
Some are called do_COMMAND() (old ones, usually), some hmp_COMMAND(),
and sometimes COMMAND pointlessly differs in spelling.
Normalize to hmp_COMMAND(), where COMMAND is exactly the command name
with '-' replaced by '_'.
Exceptions:
* do_device_add() and client_migrate_info() *not* renamed to
hmp_device_add(), hmp_client_migrate_info(), because they're also
QMP handlers. They still need to be converted to QAPI.
* do_memory_dump(), do_physical_memory_dump(), do_ioport_read(),
do_ioport_write() renamed do hmp_* instead of hmp_x(), hmp_xp(),
hmp_i(), hmp_o(), because those names are too cryptic for my taste.
* do_info_help() renamed to hmp_info_help() instead of hmp_info(),
because it only covers help.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-02-06 13:55:43 +01:00
|
|
|
void hmp_drive_add(Monitor *mon, const QDict *qdict);
|
2010-08-23 23:43:10 +02:00
|
|
|
|
2010-12-24 04:14:14 +01:00
|
|
|
/* pcie aer error injection */
|
2015-03-05 17:48:49 +01:00
|
|
|
void hmp_pcie_aer_inject_error(Monitor *mon, const QDict *qdict);
|
2010-12-24 04:14:14 +01:00
|
|
|
|
2007-11-17 18:14:51 +01:00
|
|
|
/* serial ports */
|
|
|
|
|
|
2018-04-20 16:52:42 +02:00
|
|
|
/* Return the Chardev for serial port i, or NULL if none */
|
|
|
|
|
Chardev *serial_hd(int i);
|
2018-04-20 16:52:49 +02:00
|
|
|
/* return the number of serial ports defined by the user. serial_hd(i)
|
|
|
|
|
* will always return NULL for any i which is greater than or equal to this.
|
|
|
|
|
*/
|
|
|
|
|
int serial_max_hds(void);
|
2018-04-20 16:52:42 +02:00
|
|
|
|
2007-11-17 18:14:51 +01:00
|
|
|
/* parallel ports */
|
|
|
|
|
|
|
|
|
|
#define MAX_PARALLEL_PORTS 3
|
|
|
|
|
|
2016-12-07 14:20:22 +01:00
|
|
|
extern Chardev *parallel_hds[MAX_PARALLEL_PORTS];
|
2007-11-17 18:14:51 +01:00
|
|
|
|
2015-02-06 14:18:24 +01:00
|
|
|
void hmp_info_usb(Monitor *mon, const QDict *qdict);
|
2007-11-17 18:14:51 +01:00
|
|
|
|
2010-12-08 12:35:05 +01:00
|
|
|
void add_boot_device_path(int32_t bootindex, DeviceState *dev,
|
|
|
|
|
const char *suffix);
|
2018-08-10 14:40:27 +02:00
|
|
|
char *get_boot_devices_list(size_t *size);
|
2012-09-02 21:25:28 +02:00
|
|
|
|
2013-04-26 04:12:49 +02:00
|
|
|
DeviceState *get_boot_device(uint32_t position);
|
2014-10-07 10:00:06 +02:00
|
|
|
void check_boot_index(int32_t bootindex, Error **errp);
|
2014-10-07 10:00:07 +02:00
|
|
|
void del_boot_device_path(DeviceState *dev, const char *suffix);
|
2014-10-07 10:00:11 +02:00
|
|
|
void device_add_bootindex_property(Object *obj, int32_t *bootindex,
|
|
|
|
|
const char *name, const char *suffix,
|
|
|
|
|
DeviceState *dev, Error **errp);
|
2014-12-03 17:49:46 +01:00
|
|
|
void restore_boot_order(void *opaque);
|
2014-12-03 18:11:39 +01:00
|
|
|
void validate_bootdevices(const char *devices, Error **errp);
|
2014-12-03 17:49:46 +01:00
|
|
|
|
2015-09-04 20:37:09 +02:00
|
|
|
/* handler to set the boot_device order for a specific type of MachineClass */
|
2014-12-03 20:04:02 +01:00
|
|
|
typedef void QEMUBootSetHandler(void *opaque, const char *boot_order,
|
|
|
|
|
Error **errp);
|
2014-12-03 17:49:46 +01:00
|
|
|
void qemu_register_boot_set(QEMUBootSetHandler *func, void *opaque);
|
2014-12-03 19:20:58 +01:00
|
|
|
void qemu_boot_set(const char *boot_order, Error **errp);
|
2013-04-26 04:12:49 +02:00
|
|
|
|
2013-07-04 15:09:19 +02:00
|
|
|
QemuOpts *qemu_get_machine_opts(void);
|
|
|
|
|
|
2015-01-06 14:29:12 +01:00
|
|
|
bool defaults_enabled(void);
|
2012-09-02 21:25:28 +02:00
|
|
|
|
2013-11-09 05:15:47 +01:00
|
|
|
extern QemuOptsList qemu_legacy_drive_opts;
|
|
|
|
|
extern QemuOptsList qemu_common_drive_opts;
|
2012-11-26 16:03:42 +01:00
|
|
|
extern QemuOptsList qemu_drive_opts;
|
2016-10-06 11:33:17 +02:00
|
|
|
extern QemuOptsList bdrv_runtime_opts;
|
2012-11-26 16:03:42 +01:00
|
|
|
extern QemuOptsList qemu_chardev_opts;
|
|
|
|
|
extern QemuOptsList qemu_device_opts;
|
|
|
|
|
extern QemuOptsList qemu_netdev_opts;
|
2018-02-21 11:18:36 +01:00
|
|
|
extern QemuOptsList qemu_nic_opts;
|
2012-11-26 16:03:42 +01:00
|
|
|
extern QemuOptsList qemu_net_opts;
|
|
|
|
|
extern QemuOptsList qemu_global_opts;
|
|
|
|
|
extern QemuOptsList qemu_mon_opts;
|
2019-05-13 15:43:57 +02:00
|
|
|
extern QemuOptsList qemu_semihosting_config_opts;
|
2012-11-26 16:03:42 +01:00
|
|
|
|
2007-11-17 18:14:51 +01:00
|
|
|
#endif
|
