Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 14 12月, 2018 6 次提交
  3. 12 12月, 2018 3 次提交
    • A
      crypto: Fix defaults in QCryptoBlockCreateOptionsLUKS · a8b826d4
      由 Alberto Garcia 提交于 
      The values specified in the documentation don't match the actual
defaults set in qcrypto_block_luks_create().
Signed-off-by: NAlberto Garcia <berto@igalia.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      a8b826d4
    • P
      monitor: Suspend monitor instead dropping commands · 9ab84470
      由 Peter Xu 提交于 
      When a QMP client sends in-band commands more quickly that we can
process them, we can either queue them without limit (QUEUE), drop
commands when the queue is full (DROP), or suspend receiving commands
when the queue is full (SUSPEND).  None of them is ideal:

* QUEUE lets a misbehaving client make QEMU eat memory without bounds.
Not such a hot idea.

* With DROP, the client has to cope with dropped in-band commands.  To
inform the client, we send a COMMAND_DROPPED event then.  The event is
flawed by design in two ways: it's ambiguous (see commit d621cfe0),
and it brings back the "eat memory without bounds" problem.

* With SUSPEND, the client has to manage the flow of in-band commands to
keep the monitor available for out-of-band commands.

We currently DROP.  Switch to SUSPEND.

Managing the flow of in-band commands to keep the monitor available for
out-of-band commands isn't really hard: just count the number of
"outstanding" in-band commands (commands sent minus replies received),
and if it exceeds the limit, hold back additional ones until it drops
below the limit again.

Note that we need to be careful pairing the suspend with a resume, or
else the monitor will hang, possibly forever.  And here since we need to
make sure both:

     (1) popping request from the req queue, and
     (2) reading length of the req queue

will be in the same critical section, we let the pop function take the
corresponding queue lock when there is a request, then we release the
lock from the caller.
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NPeter Xu <peterx@redhat.com>
Message-Id: <20181009062718.1914-2-peterx@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      9ab84470
    • K
      Deprecate QMP `cpu-add` · 3800db78
      由 Kashyap Chamarthy 提交于 
      The intended functionality of QMP `cpu-add` is replaced with
`device_add` (and `query-hotpluggable-cpus`).  So let's deprecate
`cpu-add`.

A complete example of vCPU hotplug with the recommended way (using
`device_add`) is provided as part of a seperate docs patch.

Suggested-by: Eduardo Habkost <ehabkost@redhat.com
Signed-off-by: NKashyap Chamarthy <kchamart@redhat.com>
Message-Id: <20181030123526.26415-2-kchamart@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      3800db78
  5. 27 11月, 2018 1 次提交
  7. 16 11月, 2018 1 次提交
  9. 05 11月, 2018 1 次提交
    • K
      block: Add auto-read-only option · e35bdc12
      由 Kevin Wolf 提交于 
      If a management application builds the block graph node by node, the
protocol layer doesn't inherit its read-only option from the format
layer any more, so it must be set explicitly.

Backing files should work on read-only storage, but at the same time, a
block job like commit should be able to reopen them read-write if they
are on read-write storage. However, without option inheritance, reopen
only changes the read-only option for the root node (typically the
format layer), but not the protocol layer, so reopening fails (the
format layer wants to get write permissions, but the protocol layer is
still read-only).

A simple workaround for the problem in the management tool would be to
open the protocol layer always read-write and to make only the format
layer read-only for backing files. However, sometimes the file is
actually stored on read-only storage and we don't know whether the image
can be opened read-write (for example, for NBD it depends on the server
we're trying to connect to). This adds an option that makes QEMU try to
open the image read-write, but allows it to degrade to a read-only mode
without returning an error.

The documentation for this option is consciously phrased in a way that
allows QEMU to switch to a better model eventually: Instead of trying
when the image is first opened, making the read-only flag dynamic and
changing it automatically whenever the first BLK_PERM_WRITE user is
attached or the last one is detached would be much more useful
behaviour.

Unfortunately, this more useful behaviour is also a lot harder to
implement, and libvirt needs a solution now before it can switch to
-blockdev, so let's start with this easier approach for now.

Instead of adding a new auto-read-only option, turning the existing
read-only into an enum (with a bool alternate for compatibility) was
considered, but it complicated the implementation to the point that it
didn't seem to be worth it.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
      e35bdc12
  11. 01 11月, 2018 1 次提交
  13. 31 10月, 2018 1 次提交
  15. 30 10月, 2018 2 次提交
  17. 24 10月, 2018 1 次提交
  19. 22 10月, 2018 1 次提交
  21. 19 10月, 2018 4 次提交
  23. 12 10月, 2018 1 次提交
  25. 09 10月, 2018 1 次提交
  27. 02 10月, 2018 1 次提交
  29. 01 10月, 2018 2 次提交
  31. 27 9月, 2018 1 次提交
  33. 26 9月, 2018 1 次提交
  35. 25 9月, 2018 7 次提交
  37. 30 8月, 2018 1 次提交
  39. 28 8月, 2018 1 次提交
  41. 25 8月, 2018 2 次提交
    • M
      json: Update references to RFC 7159 to RFC 8259 · 37aded92
      由 Markus Armbruster 提交于 
      RFC 8259 (December 2017) obsoletes RFC 7159 (March 2014).
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20180823164025.12553-59-armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
      37aded92
    • M
      qjson: Have qobject_from_json() & friends reject empty and blank · dd98e848
      由 Markus Armbruster 提交于 
      The last case where qobject_from_json() & friends return null without
setting an error is empty or blank input.  Callers:

* block.c's parse_json_protocol() reports "Could not parse the JSON
  options".  It's marked as a work-around, because it also covered
  actual bugs, but they got fixed in the previous few commits.

* qobject_input_visitor_new_str() reports "JSON parse error".  Also
  marked as work-around.  The recent fixes have made this unreachable,
  because it currently gets called only for input starting with '{'.

* check-qjson.c's empty_input() and blank_input() demonstrate the
  behavior.

* The other callers are not affected since they only pass input with
  exactly one JSON value or, in the case of negative tests, one error.

Fail with "Expecting a JSON value" instead of returning null, and
simplify callers.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-Id: <20180823164025.12553-48-armbru@redhat.com>
      dd98e848