qemu-e2k/hmp-commands.hx

1747 lines
51 KiB
Haxe
Raw Normal View History

HXCOMM Use DEFHEADING() to define headings in both help text and rST.
HXCOMM Text between SRST and ERST is copied to the rST version and
HXCOMM discarded from C version.
HXCOMM DEF(command, args, callback, arg_string, help) is used to construct
HXCOMM monitor commands
HXCOMM HXCOMM can be used for comments, discarded from both rST and C.
{
.name = "help|?",
.args_type = "name:S?",
.params = "[cmd]",
.help = "show the help",
.cmd = do_help_cmd,
.flags = "p",
},
SRST
``help`` or ``?`` [*cmd*]
Show the help for all commands or just for command *cmd*.
ERST
{
.name = "commit",
.args_type = "device:B",
.params = "device|all",
.help = "commit changes to the disk images (if -snapshot is used) or backing files",
.cmd = hmp_commit,
},
SRST
``commit``
Commit changes to the disk images (if -snapshot is used) or backing files.
If the backing file is smaller than the snapshot, then the backing file
will be resized to be the same size as the snapshot. If the snapshot is
smaller than the backing file, the backing file will not be truncated.
If you want the backing file to match the size of the smaller snapshot,
you can safely truncate it yourself once the commit operation successfully
completes.
ERST
{
.name = "quit|q",
.args_type = "",
.params = "",
.help = "quit the emulator",
.cmd = hmp_quit,
.flags = "p",
},
SRST
``quit`` or ``q``
Quit the emulator.
ERST
{
.name = "exit_preconfig",
.args_type = "",
.params = "",
.help = "exit the preconfig state",
.cmd = hmp_exit_preconfig,
.flags = "p",
},
SRST
``exit_preconfig``
This command makes QEMU exit the preconfig state and proceed with
VM initialization using configuration data provided on the command line
and via the QMP monitor during the preconfig state. The command is only
available during the preconfig state (i.e. when the --preconfig command
line option was in use).
ERST
{
.name = "block_resize",
.args_type = "device:B,size:o",
.params = "device size",
.help = "resize a block image",
.cmd = hmp_block_resize,
.coroutine = true,
},
SRST
``block_resize``
Resize a block image while a guest is running. Usually requires guest
action to see the updated size. Resize to a lower size is supported,
but should be used with extreme caution. Note that this command only
resizes image files, it can not resize block devices like LVM volumes.
ERST
{
.name = "block_stream",
.args_type = "device:B,speed:o?,base:s?",
.params = "device [speed [base]]",
.help = "copy data from a backing file into a block device",
.cmd = hmp_block_stream,
},
SRST
``block_stream``
Copy data from a backing file into a block device.
ERST
{
.name = "block_job_set_speed",
.args_type = "device:B,speed:o",
.params = "device speed",
.help = "set maximum speed for a background block operation",
.cmd = hmp_block_job_set_speed,
},
SRST
``block_job_set_speed``
Set maximum speed for a background block operation.
ERST
{
.name = "block_job_cancel",
.args_type = "force:-f,device:B",
.params = "[-f] device",
.help = "stop an active background block operation (use -f"
block/mirror: change the semantic of 'force' of block-job-cancel When doing drive mirror to a low speed shared storage, if there was heavy BLK IO write workload in VM after the 'ready' event, drive mirror block job can't be canceled immediately, it would keep running until the heavy BLK IO workload stopped in the VM. Libvirt depends on the current block-job-cancel semantics, which is that when used without a flag after the 'ready' event, the command blocks until data is in sync. However, these semantics are awkward in other situations, for example, people may use drive mirror for realtime backups while still wanting to use block live migration. Libvirt cannot start a block live migration while another drive mirror is in progress, but the user would rather abandon the backup attempt as broken and proceed with the live migration than be stuck waiting for the current drive mirror backup to finish. The drive-mirror command already includes a 'force' flag, which libvirt does not use, although it documented the flag as only being useful to quit a job which is paused. However, since quitting a paused job has the same effect as abandoning a backup in a non-paused job (namely, the destination file is not in sync, and the command completes immediately), we can just improve the documentation to make the force flag obviously useful. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Jeff Cody <jcody@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: Max Reitz <mreitz@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: John Snow <jsnow@redhat.com> Reported-by: Huaitong Han <huanhuaitong@didichuxing.com> Signed-off-by: Huaitong Han <huanhuaitong@didichuxing.com> Signed-off-by: Liang Li <liliangleo@didichuxing.com> Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-13 13:12:16 +01:00
"\n\t\t\t if you want to abort the operation immediately"
"\n\t\t\t instead of keep running until data is in sync)",
.cmd = hmp_block_job_cancel,
},
SRST
``block_job_cancel``
Stop an active background block operation (streaming, mirroring).
ERST
{
.name = "block_job_complete",
.args_type = "device:B",
.params = "device",
.help = "stop an active background block operation",
.cmd = hmp_block_job_complete,
},
SRST
``block_job_complete``
Manually trigger completion of an active background block operation.
For mirroring, this will switch the device to the destination path.
ERST
{
.name = "block_job_pause",
.args_type = "device:B",
.params = "device",
.help = "pause an active background block operation",
.cmd = hmp_block_job_pause,
},
SRST
``block_job_pause``
Pause an active block streaming operation.
ERST
{
.name = "block_job_resume",
.args_type = "device:B",
.params = "device",
.help = "resume a paused background block operation",
.cmd = hmp_block_job_resume,
},
SRST
``block_job_resume``
Resume a paused block streaming operation.
ERST
{
.name = "eject",
.args_type = "force:-f,device:B",
.params = "[-f] device",
.help = "eject a removable medium (use -f to force it)",
.cmd = hmp_eject,
},
SRST
``eject [-f]`` *device*
Eject a removable medium (use -f to force it).
ERST
{
.name = "drive_del",
.args_type = "id:B",
.params = "device",
.help = "remove host block device",
.cmd = hmp_drive_del,
},
SRST
``drive_del`` *device*
Remove host block device. The result is that guest generated IO is no longer
submitted against the host device underlying the disk. Once a drive has
been deleted, the QEMU Block layer returns -EIO which results in IO
errors in the guest for applications that are reading/writing to the device.
These errors are always reported to the guest, regardless of the drive's error
actions (drive options rerror, werror).
ERST
{
.name = "change",
.args_type = "device:B,target:F,arg:s?,read-only-mode:s?",
.params = "device filename [format [read-only-mode]]",
.help = "change a removable medium, optional format",
.cmd = hmp_change,
},
SRST
``change`` *device* *setting*
Change the configuration of a device.
``change`` *diskdevice* *filename* [*format* [*read-only-mode*]]
Change the medium for a removable disk device to point to *filename*. eg::
(qemu) change ide1-cd0 /path/to/some.iso
*format* is optional.
*read-only-mode* may be used to change the read-only status of the device.
It accepts the following values:
retain
Retains the current status; this is the default.
read-only
Makes the device read-only.
read-write
Makes the device writable.
``change vnc password`` [*password*]
Change the password associated with the VNC server. If the new password
is not supplied, the monitor will prompt for it to be entered. VNC
passwords are only significant up to 8 letters. eg::
(qemu) change vnc password
Password: ********
ERST
{
.name = "screendump",
.args_type = "filename:F,device:s?,head:i?",
.params = "filename [device [head]]",
.help = "save screen from head 'head' of display device 'device' "
"into PPM image 'filename'",
.cmd = hmp_screendump,
.coroutine = true,
},
SRST
``screendump`` *filename*
Save screen into PPM image *filename*.
ERST
{
.name = "logfile",
.args_type = "filename:F",
.params = "filename",
.help = "output logs to 'filename'",
.cmd = hmp_logfile,
},
SRST
``logfile`` *filename*
Output logs to *filename*.
ERST
{
.name = "trace-event",
.args_type = "name:s,option:b,vcpu:i?",
.params = "name on|off [vcpu]",
.help = "changes status of a specific trace event "
"(vcpu: vCPU to set, default is all)",
.cmd = hmp_trace_event,
.command_completion = trace_event_completion,
},
SRST
``trace-event``
changes status of a trace event
ERST
trace: Add trace-file command to open/close/flush trace file This patch adds the trace-file command: trace-file [on|off|flush] Open, close, or flush the trace file. If no argument is given, the status of the trace file is displayed. The trace file is turned on by default but is only written out when the trace buffer becomes full. The flush operation can be used to force write out at any time. Turning off the trace file does not change the state of trace events; tracing will continue to the trace buffer. When the trace file is off, use "info trace" to display the contents of the trace buffer in memory. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> This commit also contains the trace-file sub-command from the following commit: commit 5ce8d1a957afae2c52ad748944ce72848ccf57bd Author: Prerna Saxena <prerna@linux.vnet.ibm.com> Date: Wed Aug 4 16:23:54 2010 +0530 trace: Add options to specify trace file name at startup and runtime This patch adds an optional command line switch '-trace' to specify the filename to write traces to, when qemu starts. Eg, If compiled with the 'simple' trace backend, [temp@system]$ qemu -trace FILENAME IMAGE Allows the binary traces to be written to FILENAME instead of the option set at config-time. Also, this adds monitor sub-command 'set' to trace-file commands to dynamically change trace log file at runtime. Eg, (qemu)trace-file set FILENAME This allows one to set trace outputs to FILENAME from the default specified at startup. Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2010-07-13 10:26:33 +02:00
#if defined(CONFIG_TRACE_SIMPLE)
trace: Add trace-file command to open/close/flush trace file This patch adds the trace-file command: trace-file [on|off|flush] Open, close, or flush the trace file. If no argument is given, the status of the trace file is displayed. The trace file is turned on by default but is only written out when the trace buffer becomes full. The flush operation can be used to force write out at any time. Turning off the trace file does not change the state of trace events; tracing will continue to the trace buffer. When the trace file is off, use "info trace" to display the contents of the trace buffer in memory. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> This commit also contains the trace-file sub-command from the following commit: commit 5ce8d1a957afae2c52ad748944ce72848ccf57bd Author: Prerna Saxena <prerna@linux.vnet.ibm.com> Date: Wed Aug 4 16:23:54 2010 +0530 trace: Add options to specify trace file name at startup and runtime This patch adds an optional command line switch '-trace' to specify the filename to write traces to, when qemu starts. Eg, If compiled with the 'simple' trace backend, [temp@system]$ qemu -trace FILENAME IMAGE Allows the binary traces to be written to FILENAME instead of the option set at config-time. Also, this adds monitor sub-command 'set' to trace-file commands to dynamically change trace log file at runtime. Eg, (qemu)trace-file set FILENAME This allows one to set trace outputs to FILENAME from the default specified at startup. Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2010-07-13 10:26:33 +02:00
{
.name = "trace-file",
.args_type = "op:s?,arg:F?",
.params = "on|off|flush|set [arg]",
.help = "open, close, or flush trace file, or set a new file name",
.cmd = hmp_trace_file,
trace: Add trace-file command to open/close/flush trace file This patch adds the trace-file command: trace-file [on|off|flush] Open, close, or flush the trace file. If no argument is given, the status of the trace file is displayed. The trace file is turned on by default but is only written out when the trace buffer becomes full. The flush operation can be used to force write out at any time. Turning off the trace file does not change the state of trace events; tracing will continue to the trace buffer. When the trace file is off, use "info trace" to display the contents of the trace buffer in memory. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> This commit also contains the trace-file sub-command from the following commit: commit 5ce8d1a957afae2c52ad748944ce72848ccf57bd Author: Prerna Saxena <prerna@linux.vnet.ibm.com> Date: Wed Aug 4 16:23:54 2010 +0530 trace: Add options to specify trace file name at startup and runtime This patch adds an optional command line switch '-trace' to specify the filename to write traces to, when qemu starts. Eg, If compiled with the 'simple' trace backend, [temp@system]$ qemu -trace FILENAME IMAGE Allows the binary traces to be written to FILENAME instead of the option set at config-time. Also, this adds monitor sub-command 'set' to trace-file commands to dynamically change trace log file at runtime. Eg, (qemu)trace-file set FILENAME This allows one to set trace outputs to FILENAME from the default specified at startup. Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2010-07-13 10:26:33 +02:00
},
SRST
``trace-file on|off|flush``
Open, close, or flush the trace file. If no argument is given, the
status of the trace file is displayed.
ERST
#endif
{
.name = "log",
.args_type = "items:s",
.params = "item1[,...]",
.help = "activate logging of the specified items",
.cmd = hmp_log,
},
SRST
``log`` *item1*\ [,...]
Activate logging of the specified items.
ERST
{
.name = "savevm",
.args_type = "name:s?",
block/snapshot.c: eliminate use of ID input in snapshot operations At this moment, QEMU attempts to create/load/delete snapshots by using either an ID (id_str) or a name. The problem is that the code isn't consistent of whether the entered argument is an ID or a name, causing unexpected behaviors. For example, when creating snapshots via savevm <arg>, what happens is that "arg" is treated as both name and id_str. In a guest without snapshots, create a single snapshot via savevm: (qemu) savevm 0 (qemu) info snapshots List of snapshots present on all disks: ID TAG VM SIZE DATE VM CLOCK -- 0 741M 2018-07-31 13:39:56 00:41:25.313 A snapshot with name "0" is created. ID is hidden from the user, but the ID is a non-zero integer that starts at "1". Thus, this snapshot has id_str=1, TAG="0". Creating a second snapshot with arg = 1, the first one is deleted: (qemu) savevm 1 (qemu) info snapshots List of snapshots present on all disks: ID TAG VM SIZE DATE VM CLOCK -- 1 741M 2018-07-31 13:42:14 00:41:55.252 What happened? - when creating the second snapshot, a verification is done inside bdrv_all_delete_snapshot to delete any existing snapshots that matches an string argument. Here, the code calls bdrv_all_delete_snapshot("1", ...); - bdrv_all_delete_snapshot calls bdrv_snapshot_find(..., "1") for each BlockDriverState of the guest. And this is where things goes tilting: bdrv_snapshot_find does a search by both id_str and name. It finds out that there is a snapshot that has id_str = 1, stores a reference to the snapshot in the sn_info pointer and then returns match found; - since a match was found, a call to bdrv_snapshot_delete_by_id_or_name() is made. This function ignores the pointer written by bdrv_snapshot_find. Instead, it deletes the snapshot using bdrv_snapshot_delete() calling it first with id_str = 1. If it fails to delete, then it calls it again with name = 1. - after all that, QEMU creates the new snapshot, that has id_str = 1 and name = 1. The user is left wondering that happened with the first snapshot created. Similar bugs can be triggered when using loadvm and delvm. Before contemplating discarding the use of ID input in these operations, I've searched the code of what would be the implications. My findings are: - the RBD and Sheepdog drivers don't care. Both uses the 'name' field as key in their logic, making id_str = name when appropriate. replay-snapshot.c does not make any special use of id_str; - qcow2 uses id_str as an unique identifier but it is automatically calculated, not being influenced by user input. Other than that, there are no distinguish operations made only with id_str; - in blockdev.c, the delete operation uses a match of both id_str AND name. Given that id_str is either a copy of 'name' or auto-generated, we're fine here. This gives motivation to not consider ID as a valid user input in HMP commands - sticking with 'name' input only is more consistent. To accomplish that, the following changes were made in this patch: - bdrv_snapshot_find() does not match for id_str anymore, only 'name'. The function is called in save_snapshot(), load_snapshot(), bdrv_all_delete_snapshot() and bdrv_all_find_snapshot(). This change makes the search function more predictable and does not change the behavior of any underlying code that uses these affected functions, which are related to HMP (which is fine) and the main loop inside vl.c (which doesn't care about it anyways); - bdrv_all_delete_snapshot() does not call bdrv_snapshot_delete_by_id_or_name anymore. Instead, it uses the pointer returned by bdrv_snapshot_find to erase the snapshot with the exact match of id_str an name. This function is called in save_snapshot and hmp_delvm, thus this change produces the intended effect; - documentation changes to reflect the new behavior. I consider this to be an API fix instead of an API change - the user was already creating snapshots using 'name', but now he/she will also enjoy a consistent behavior. Ideally we would get rid of the id_str field entirely, but this would have repercussions on existing snapshots. Another day perhaps. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-11-07 14:09:58 +01:00
.params = "tag",
.help = "save a VM snapshot. If no tag is provided, a new snapshot is created",
.cmd = hmp_savevm,
},
SRST
``savevm`` *tag*
Create a snapshot of the whole virtual machine. If *tag* is
provided, it is used as human readable identifier. If there is already
a snapshot with the same tag, it is replaced. More info at
:ref:`vm_005fsnapshots`.
Since 4.0, savevm stopped allowing the snapshot id to be set, accepting
only *tag* as parameter.
ERST
{
.name = "loadvm",
.args_type = "name:s",
block/snapshot.c: eliminate use of ID input in snapshot operations At this moment, QEMU attempts to create/load/delete snapshots by using either an ID (id_str) or a name. The problem is that the code isn't consistent of whether the entered argument is an ID or a name, causing unexpected behaviors. For example, when creating snapshots via savevm <arg>, what happens is that "arg" is treated as both name and id_str. In a guest without snapshots, create a single snapshot via savevm: (qemu) savevm 0 (qemu) info snapshots List of snapshots present on all disks: ID TAG VM SIZE DATE VM CLOCK -- 0 741M 2018-07-31 13:39:56 00:41:25.313 A snapshot with name "0" is created. ID is hidden from the user, but the ID is a non-zero integer that starts at "1". Thus, this snapshot has id_str=1, TAG="0". Creating a second snapshot with arg = 1, the first one is deleted: (qemu) savevm 1 (qemu) info snapshots List of snapshots present on all disks: ID TAG VM SIZE DATE VM CLOCK -- 1 741M 2018-07-31 13:42:14 00:41:55.252 What happened? - when creating the second snapshot, a verification is done inside bdrv_all_delete_snapshot to delete any existing snapshots that matches an string argument. Here, the code calls bdrv_all_delete_snapshot("1", ...); - bdrv_all_delete_snapshot calls bdrv_snapshot_find(..., "1") for each BlockDriverState of the guest. And this is where things goes tilting: bdrv_snapshot_find does a search by both id_str and name. It finds out that there is a snapshot that has id_str = 1, stores a reference to the snapshot in the sn_info pointer and then returns match found; - since a match was found, a call to bdrv_snapshot_delete_by_id_or_name() is made. This function ignores the pointer written by bdrv_snapshot_find. Instead, it deletes the snapshot using bdrv_snapshot_delete() calling it first with id_str = 1. If it fails to delete, then it calls it again with name = 1. - after all that, QEMU creates the new snapshot, that has id_str = 1 and name = 1. The user is left wondering that happened with the first snapshot created. Similar bugs can be triggered when using loadvm and delvm. Before contemplating discarding the use of ID input in these operations, I've searched the code of what would be the implications. My findings are: - the RBD and Sheepdog drivers don't care. Both uses the 'name' field as key in their logic, making id_str = name when appropriate. replay-snapshot.c does not make any special use of id_str; - qcow2 uses id_str as an unique identifier but it is automatically calculated, not being influenced by user input. Other than that, there are no distinguish operations made only with id_str; - in blockdev.c, the delete operation uses a match of both id_str AND name. Given that id_str is either a copy of 'name' or auto-generated, we're fine here. This gives motivation to not consider ID as a valid user input in HMP commands - sticking with 'name' input only is more consistent. To accomplish that, the following changes were made in this patch: - bdrv_snapshot_find() does not match for id_str anymore, only 'name'. The function is called in save_snapshot(), load_snapshot(), bdrv_all_delete_snapshot() and bdrv_all_find_snapshot(). This change makes the search function more predictable and does not change the behavior of any underlying code that uses these affected functions, which are related to HMP (which is fine) and the main loop inside vl.c (which doesn't care about it anyways); - bdrv_all_delete_snapshot() does not call bdrv_snapshot_delete_by_id_or_name anymore. Instead, it uses the pointer returned by bdrv_snapshot_find to erase the snapshot with the exact match of id_str an name. This function is called in save_snapshot and hmp_delvm, thus this change produces the intended effect; - documentation changes to reflect the new behavior. I consider this to be an API fix instead of an API change - the user was already creating snapshots using 'name', but now he/she will also enjoy a consistent behavior. Ideally we would get rid of the id_str field entirely, but this would have repercussions on existing snapshots. Another day perhaps. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-11-07 14:09:58 +01:00
.params = "tag",
.help = "restore a VM snapshot from its tag",
.cmd = hmp_loadvm,
.command_completion = loadvm_completion,
},
SRST
``loadvm`` *tag*
Set the whole virtual machine to the snapshot identified by the tag
*tag*.
Since 4.0, loadvm stopped accepting snapshot id as parameter.
ERST
{
.name = "delvm",
.args_type = "name:s",
block/snapshot.c: eliminate use of ID input in snapshot operations At this moment, QEMU attempts to create/load/delete snapshots by using either an ID (id_str) or a name. The problem is that the code isn't consistent of whether the entered argument is an ID or a name, causing unexpected behaviors. For example, when creating snapshots via savevm <arg>, what happens is that "arg" is treated as both name and id_str. In a guest without snapshots, create a single snapshot via savevm: (qemu) savevm 0 (qemu) info snapshots List of snapshots present on all disks: ID TAG VM SIZE DATE VM CLOCK -- 0 741M 2018-07-31 13:39:56 00:41:25.313 A snapshot with name "0" is created. ID is hidden from the user, but the ID is a non-zero integer that starts at "1". Thus, this snapshot has id_str=1, TAG="0". Creating a second snapshot with arg = 1, the first one is deleted: (qemu) savevm 1 (qemu) info snapshots List of snapshots present on all disks: ID TAG VM SIZE DATE VM CLOCK -- 1 741M 2018-07-31 13:42:14 00:41:55.252 What happened? - when creating the second snapshot, a verification is done inside bdrv_all_delete_snapshot to delete any existing snapshots that matches an string argument. Here, the code calls bdrv_all_delete_snapshot("1", ...); - bdrv_all_delete_snapshot calls bdrv_snapshot_find(..., "1") for each BlockDriverState of the guest. And this is where things goes tilting: bdrv_snapshot_find does a search by both id_str and name. It finds out that there is a snapshot that has id_str = 1, stores a reference to the snapshot in the sn_info pointer and then returns match found; - since a match was found, a call to bdrv_snapshot_delete_by_id_or_name() is made. This function ignores the pointer written by bdrv_snapshot_find. Instead, it deletes the snapshot using bdrv_snapshot_delete() calling it first with id_str = 1. If it fails to delete, then it calls it again with name = 1. - after all that, QEMU creates the new snapshot, that has id_str = 1 and name = 1. The user is left wondering that happened with the first snapshot created. Similar bugs can be triggered when using loadvm and delvm. Before contemplating discarding the use of ID input in these operations, I've searched the code of what would be the implications. My findings are: - the RBD and Sheepdog drivers don't care. Both uses the 'name' field as key in their logic, making id_str = name when appropriate. replay-snapshot.c does not make any special use of id_str; - qcow2 uses id_str as an unique identifier but it is automatically calculated, not being influenced by user input. Other than that, there are no distinguish operations made only with id_str; - in blockdev.c, the delete operation uses a match of both id_str AND name. Given that id_str is either a copy of 'name' or auto-generated, we're fine here. This gives motivation to not consider ID as a valid user input in HMP commands - sticking with 'name' input only is more consistent. To accomplish that, the following changes were made in this patch: - bdrv_snapshot_find() does not match for id_str anymore, only 'name'. The function is called in save_snapshot(), load_snapshot(), bdrv_all_delete_snapshot() and bdrv_all_find_snapshot(). This change makes the search function more predictable and does not change the behavior of any underlying code that uses these affected functions, which are related to HMP (which is fine) and the main loop inside vl.c (which doesn't care about it anyways); - bdrv_all_delete_snapshot() does not call bdrv_snapshot_delete_by_id_or_name anymore. Instead, it uses the pointer returned by bdrv_snapshot_find to erase the snapshot with the exact match of id_str an name. This function is called in save_snapshot and hmp_delvm, thus this change produces the intended effect; - documentation changes to reflect the new behavior. I consider this to be an API fix instead of an API change - the user was already creating snapshots using 'name', but now he/she will also enjoy a consistent behavior. Ideally we would get rid of the id_str field entirely, but this would have repercussions on existing snapshots. Another day perhaps. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-11-07 14:09:58 +01:00
.params = "tag",
.help = "delete a VM snapshot from its tag",
.cmd = hmp_delvm,
.command_completion = delvm_completion,
},
SRST
``delvm`` *tag*
Delete the snapshot identified by *tag*.
Since 4.0, delvm stopped deleting snapshots by snapshot id, accepting
only *tag* as parameter.
ERST
{
.name = "singlestep",
.args_type = "option:s?",
.params = "[on|off]",
.help = "run emulation in singlestep mode or switch to normal mode",
.cmd = hmp_singlestep,
},
SRST
``singlestep [off]``
Run the emulation in single step mode.
If called with option off, the emulation returns to normal mode.
ERST
{
.name = "stop|s",
.args_type = "",
.params = "",
.help = "stop emulation",
.cmd = hmp_stop,
},
SRST
``stop`` or ``s``
Stop emulation.
ERST
{
.name = "cont|c",
.args_type = "",
.params = "",
.help = "resume emulation",
.cmd = hmp_cont,
},
SRST
``cont`` or ``c``
Resume emulation.
ERST
{
.name = "system_wakeup",
.args_type = "",
.params = "",
.help = "wakeup guest from suspend",
.cmd = hmp_system_wakeup,
},
SRST
``system_wakeup``
Wakeup guest from suspend.
ERST
{
.name = "gdbserver",
.args_type = "device:s?",
.params = "[device]",
.help = "start gdbserver on given device (default 'tcp::1234'), stop with 'none'",
.cmd = hmp_gdbserver,
},
SRST
``gdbserver`` [*port*]
Start gdbserver session (default *port*\=1234)
ERST
{
.name = "x",
.args_type = "fmt:/,addr:l",
.params = "/fmt addr",
.help = "virtual memory dump starting at 'addr'",
.cmd = hmp_memory_dump,
},
SRST
``x/``\ *fmt* *addr*
Virtual memory dump starting at *addr*.
ERST
{
.name = "xp",
.args_type = "fmt:/,addr:l",
.params = "/fmt addr",
.help = "physical memory dump starting at 'addr'",
.cmd = hmp_physical_memory_dump,
},
SRST
``xp /``\ *fmt* *addr*
Physical memory dump starting at *addr*.
*fmt* is a format which tells the command how to format the
data. Its syntax is: ``/{count}{format}{size}``
*count*
is the number of items to be dumped.
*format*
can be x (hex), d (signed decimal), u (unsigned decimal), o (octal),
c (char) or i (asm instruction).
*size*
can be b (8 bits), h (16 bits), w (32 bits) or g (64 bits). On x86,
``h`` or ``w`` can be specified with the ``i`` format to
respectively select 16 or 32 bit code instruction size.
Examples:
Dump 10 instructions at the current instruction pointer::
(qemu) x/10i $eip
0x90107063: ret
0x90107064: sti
0x90107065: lea 0x0(%esi,1),%esi
0x90107069: lea 0x0(%edi,1),%edi
0x90107070: ret
0x90107071: jmp 0x90107080
0x90107073: nop
0x90107074: nop
0x90107075: nop
0x90107076: nop
Dump 80 16 bit values at the start of the video memory::
(qemu) xp/80hx 0xb8000
0x000b8000: 0x0b50 0x0b6c 0x0b65 0x0b78 0x0b38 0x0b36 0x0b2f 0x0b42
0x000b8010: 0x0b6f 0x0b63 0x0b68 0x0b73 0x0b20 0x0b56 0x0b47 0x0b41
0x000b8020: 0x0b42 0x0b69 0x0b6f 0x0b73 0x0b20 0x0b63 0x0b75 0x0b72
0x000b8030: 0x0b72 0x0b65 0x0b6e 0x0b74 0x0b2d 0x0b63 0x0b76 0x0b73
0x000b8040: 0x0b20 0x0b30 0x0b35 0x0b20 0x0b4e 0x0b6f 0x0b76 0x0b20
0x000b8050: 0x0b32 0x0b30 0x0b30 0x0b33 0x0720 0x0720 0x0720 0x0720
0x000b8060: 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720
0x000b8070: 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720
0x000b8080: 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720
0x000b8090: 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720
ERST
{
.name = "gpa2hva",
.args_type = "addr:l",
.params = "addr",
.help = "print the host virtual address corresponding to a guest physical address",
.cmd = hmp_gpa2hva,
},
SRST
``gpa2hva`` *addr*
Print the host virtual address at which the guest's physical address *addr*
is mapped.
ERST
#ifdef CONFIG_LINUX
{
.name = "gpa2hpa",
.args_type = "addr:l",
.params = "addr",
.help = "print the host physical address corresponding to a guest physical address",
.cmd = hmp_gpa2hpa,
},
#endif
SRST
``gpa2hpa`` *addr*
Print the host physical address at which the guest's physical address *addr*
is mapped.
ERST
{
.name = "gva2gpa",
.args_type = "addr:l",
.params = "addr",
.help = "print the guest physical address corresponding to a guest virtual address",
.cmd = hmp_gva2gpa,
},
SRST
``gva2gpa`` *addr*
Print the guest physical address at which the guest's virtual address *addr*
is mapped based on the mapping for the current CPU.
ERST
{
.name = "print|p",
.args_type = "fmt:/,val:l",
.params = "/fmt expr",
.help = "print expression value (use $reg for CPU register access)",
.cmd = do_print,
},
SRST
``print`` or ``p/``\ *fmt* *expr*
Print expression value. Only the *format* part of *fmt* is
used.
ERST
{
.name = "i",
.args_type = "fmt:/,addr:i,index:i.",
.params = "/fmt addr",
.help = "I/O port read",
.cmd = hmp_ioport_read,
},
SRST
``i/``\ *fmt* *addr* [.\ *index*\ ]
Read I/O port.
<