Skip to content
Snippets Groups Projects
Select Git revision
  • feature/libtcg-rebase default protected
1 result
Search by author
  • Any Author
  • Anton Anton anjo
1 author
  1. Mar 02, 2022
  3. Nov 09, 2021
  5. Nov 01, 2021
  7. Sep 27, 2021
  9. Jun 11, 2021
  11. Jun 08, 2021
  13. May 26, 2021
  15. May 25, 2021
  17. Mar 23, 2021
  19. Mar 19, 2021
  21. Mar 18, 2021
  23. Jan 23, 2021
    • Paolo Bonzini's avatar
      hmp: remove "change vnc TARGET" command · cfb5387a
      Paolo Bonzini authored 
      
The HMP command \"change vnc TARGET\" is messy:

- it takes an ugly shortcut to determine if the option has an "id",
with incorrect results if "id=" is not preceded by an unescaped
comma.

- it deletes the existing QemuOpts and does not try to rollback
if the parsing fails (which is not causing problems, but only due to
how VNC options are parsed)

- because it uses the same parsing function as "-vnc", it forces
the latter to not support "-vnc help".

On top of this, it uses a deprecated QMP command, thus getting in
the way of removing the QMP command.  Since the usecase for the
command is not clear, just remove it and send "change vnc password"
directly to the QMP "change-vnc-password" command.

Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: default avatarEric Blake <eblake@redhat.com>
Reviewed-by: default avatarGerd Hoffmann <kraxel@redhat.com>
Message-Id: <20210120144235.345983-2-pbonzini@redhat.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      cfb5387a
  25. Dec 18, 2020
  27. Dec 15, 2020
  29. Dec 09, 2020
  31. Nov 04, 2020
  33. Oct 09, 2020
    • Kevin Wolf's avatar
      block: Convert 'block_resize' to coroutine · eb94b81a
      Kevin Wolf authored 
      
block_resize performs some I/O that could potentially take quite some
time, so use it as an example for the new 'coroutine': true annotation
in the QAPI schema.

bdrv_truncate() requires that we're already in the right AioContext for
the BlockDriverState if called in coroutine context. So instead of just
taking the AioContext lock, move the QMP handler coroutine to the
context.

Call blk_unref() only after switching back because blk_unref() may only
be called in the main thread.

Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
Message-Id: <20201005155855.256490-15-kwolf@redhat.com>
Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      eb94b81a
  35. Oct 06, 2020
  37. Sep 29, 2020
  39. Sep 17, 2020
  41. Jun 17, 2020
    • David Hildenbrand's avatar
      hmp: Make json format optional for qom-set · 2d9e3dd9
      David Hildenbrand authored 
      
Commit 7d2ef6dc ("hmp: Simplify qom-set") switched to the json
parser, making it possible to specify complex types. However, with this
change it is no longer possible to specify proper sizes (e.g., 2G, 128M),
turning the interface harder to use for properties that consume sizes.

Let's switch back to the previous handling and allow to specify passing
json via the "-j" parameter.

Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
Message-Id: <20200610075153.33892-1-david@redhat.com>
Reviewed-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>
      2d9e3dd9
  43. Jun 01, 2020
  45. Mar 12, 2020
  47. Mar 09, 2020
  49. Mar 06, 2020
  51. Dec 19, 2019
    • Kevin Wolf's avatar
      hmp: Allow using qdev ID for qemu-io command · 89b6fc45
      Kevin Wolf authored 
      
In order to issue requests on an existing BlockBackend with the
'qemu-io' HMP command, allow specifying the BlockBackend not only with a
BlockBackend name, but also with a qdev ID/QOM path for a device that
owns the (possibly anonymous) BlockBackend.

Because qdev names could be conflicting with BlockBackend and node
names, introduce a -d option to explicitly address a device. If the
option is not given, a BlockBackend or a node is addressed.

Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      89b6fc45
  53. Aug 21, 2019
  55. Jul 02, 2019
  57. Jun 17, 2019
  59. May 01, 2019
    • Dr. David Alan Gilbert's avatar
      hmp: gva2gpa debug command · 574d9693
      Dr. David Alan Gilbert authored 
      
Add a gva2gpa command purely for debug which performs
address translation on the gva, the existing gpa2hva
command can then also be used to find it in the qemu
userspace; e.g.

(qemu) info registers
.... RSP=ffffffff81c03e98
....
(qemu) gva2gpa 0xffffffff81c03e98
gpa: 0x1c03e98
(qemu) gpa2hva 0x1c03e98
Host virtual address for 0x1c03e98 (pc.ram) is 0x7f0599a03e98
(qemu) x/10x 0xffffffff81c03e98
ffffffff81c03e98: 0x81c03eb8 0xffffffff 0x8101ea3f 0xffffffff
ffffffff81c03ea8: 0x81d27b00 0xffffffff 0x00000000 0x00000000
ffffffff81c03eb8: 0x81c03ec8 0xffffffff

gdb -p ...qemu...
(gdb) x/10x 0x7f0599a03e98
0x7f0599a03e98:	0x81c03eb8	0xffffffff	0x8101ea3f	0xffffffff
0x7f0599a03ea8:	0x81d27b00	0xffffffff	0x00000000	0x00000000
0x7f0599a03eb8:	0x81c03ec8	0xffffffff

Signed-off-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20190412152652.827-1-dgilbert@redhat.com>
Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>
      574d9693
  61. Mar 05, 2019
  63. Feb 25, 2019
    • Daniel Henrique Barboza's avatar
      block/snapshot.c: eliminate use of ID input in snapshot operations · 6ca08045
      Daniel Henrique Barboza authored 
      
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: default avatarDaniel Henrique Barboza <danielhb413@gmail.com>
Acked-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      6ca08045
  65. Dec 11, 2018
  67. Aug 23, 2018