Add 'if' key to union members:

{ 'union': 'TestIfUnion', 'data':
    'mem': { 'type': 'str', 'if': 'COND'} }

The generated code remains unconditional for now. Later patches
generate the conditionals.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20181213123724.4866-16-marcandre.lureau@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

The generated code is for now *unconditional*.  Later patches generate
the conditionals.

Note that union discriminators may not have 'if' conditionals.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20181213123724.4866-14-marcandre.lureau@redhat.com>
Message-Id: <20181213123724.4866-15-marcandre.lureau@redhat.com>
[Patches squashed, commit message tweaked]
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Wherever a struct/union/alternate/command/event member with NAME: TYPE
form is accepted, desugar it to a NAME: { 'type': TYPE } form.

This will allow to add new member details, such as 'if' in the
following patch to introduce conditionals, or 'default' for default
values etc.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20181213123724.4866-13-marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Add condition to QAPIEvent enum members based on the event 'if'.

The generated code remains unconditional for now. Later patches
generate the conditionals (also there is no additional coverage of
this change in qapi-schema-test.out since the event_names enum is an
implicit type created by qapi/events.py).
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20181213123724.4866-11-marcandre.lureau@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

QAPISchemaMember gains .ifcond for enum members: inherited classes,
such as QAPISchemaObjectTypeMember, will thus have an ifcond member
after this (those different types will also use the .ifcond to store
the condition and generate conditional code in the following patches).

The generated code remains unconditional for now. Later patches
generate the conditionals.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20181213123724.4866-10-marcandre.lureau@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Desugar the enum NAME form to { 'name': NAME }. This will allow to add
new enum members, such as 'if' in the following patch.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20181213123724.4866-7-marcandre.lureau@redhat.com>
Message-Id: <20181213123724.4866-8-marcandre.lureau@redhat.com>
Message-Id: <20181213123724.4866-9-marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
[Harmless accidental move backed out, long line wrapped, patches
squashed]
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Report the set of missing or unknown keys. And give a hint about the
accepted keys.

The error message for multiple meta type members (visible in
tests/qapi-schema/double-type.err) is not improved.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20181213123724.4866-6-marcandre.lureau@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Introduce a new helper function to check if the given keys are known,
and if mandatory keys are present. The function will be reused in
other places in the following code changes.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20181213123724.4866-5-marcandre.lureau@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Commit 93bda4dd changed the internal representation of enum type
members from str to QAPISchemaMember, but we still print only a
string.  Has been good enough, as the name is the member's only
attribute of interest, but that's about to change.  To prepare, print
them more like object type members.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20181213123724.4866-4-marcandre.lureau@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

This will allow to add and access more properties associated with enum
values/members, like the associated 'if' condition. We may want to
have a specialized type QAPISchemaEnumMember, for now this will do.

Modify gen_enum() and gen_enum_lookup() for the same reason.
Suggested-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20181213123724.4866-3-marcandre.lureau@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

The generated C enumeration types explicitly set the enumeration
constants to 0, 1, 2, ...  That's exactly what you get when you don't
supply values.

Drop the explicit values.  No change now, but it will avoid gaps in
the values when we later add support for 'if' conditions.  Avoiding
such gaps will save us the trouble of changing the ENUM_lookup[]
tables to work without a sentinel.

We'll have to take care to ensure the headers required by the 'if'
conditions get always included before the generated QAPI code.
Fortunately, our convention to include "qemu/osdep.h" first in any .c
ensures that's the case for our CONFIG_FOO macros.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20181213123724.4866-2-marcandre.lureau@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Let's break the line before 'data'. While at it, improve a bit
indentation/spacing. (I removed some alignment which are not helping
much readability and become quickly inconsistent)
Suggested-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20181208111606.8505-26-marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Rename QAPISchemaEnumType.values and related variables to members.
Makes sense ever since commit 93bda4dd changed .values from list of
string to list of QAPISchemaMember. Obvious no-op.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20181208111606.8505-4-marcandre.lureau@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Forgotten in commit 967c8851.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20181208111606.8505-19-marcandre.lureau@redhat.com>
Message-Id: <20181208111606.8505-21-marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
[Squashed, commit message adjusted]
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

The JSON parser happily accepts duplicate object member names.  The
last value wins.  Reproducer #1:

    $ qemu-system-x86_64 -qmp stdio
    {"QMP": {"version": {"qemu": {"micro": 93, "minor": 0, "major": 3},
    "package": "v3.1.0-rc3-7-g87a45d86ed"}, "capabilities": []}}
    {'execute':'qmp_capabilities'}
    {"return": {}}
    {'execute':'blockdev-add','arguments':{'driver':'null-co',
     'node-name':'foo','node-name':'bar'}}
    {"return": {}}
    {'execute':'query-named-block-nodes'}
    {"return": [{ [...] "node-name": "bar" [...] }]}

Reproducer #2 is iotest 229.

Fix the parser to reject duplicates, and fix iotest 229 not to use
them.
Reported-by: NMax Reitz <mreitz@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20181206121743.20762-1-armbru@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
[Trailing whitespace tidied up]
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

RFC8259 obsoletes RFC7159. Fix a couple of URLs to point to the
newer version.
Signed-off-by: NEric Blake <eblake@redhat.com>
Message-Id: <20181203175702.128701-1-eblake@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Let's make sure that the range handling code can properly deal with
ranges that end at the biggest possible number.
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Message-Id: <20181121164421.20780-10-david@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Basically copy all int64 list tests but adapt them to work on uint64
instead. The values for very big/very small values have to be adapted.
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Message-Id: <20181121164421.20780-9-david@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

We now support virtual walks, so use that instead.
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Message-Id: <20181121164421.20780-8-david@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

The input visitor has some problems right now, especially
- unsigned type "Range" is used to process signed ranges, resulting in
  inconsistent behavior and ugly/magical code
- uint64_t are parsed like int64_t, so big uint64_t values are not
  supported and error messages are misleading
- lists/ranges of int64_t are accepted although no list is parsed and
  we should rather report an error
- lists/ranges are preparsed using int64_t, making it hard to
  implement uint64_t values or uint64_t lists
- types that don't support lists don't bail out
- visiting beyond the end of a list is not handled properly
- we don't actually parse lists, we parse *sets*: members are sorted,
  and duplicates eliminated

So let's rewrite it by getting rid of usage of the type "Range" and
properly supporting lists of int64_t and uint64_t (including ranges of
both types), fixing the above mentioned issues.

Lists of other types are not supported and will properly report an
error. Virtual walks are now supported.

Tests have to be fixed up:
- Two BUGs were hardcoded that are fixed now
- The string-input-visitor now actually returns a parsed list and not
  an ordered set.

Please note that no users/callers have to be fixed up. Candidates using
visit_type_uint16List() and friends are:
- backends/hostmem.c:host_memory_backend_set_host_nodes()
-- Code can deal with duplicates/unsorted lists
- numa.c::query_memdev()
-- via object_property_get_uint16List(), the list will still be sorted
   and without duplicates (via host_memory_backend_get_host_nodes())
- qapi-visit.c::visit_type_Memdev_members()
- qapi-visit.c::visit_type_NumaNodeOptions_members()
- qapi-visit.c::visit_type_RockerOfDpaGroup_members
- qapi-visit.c::visit_type_RxFilterInfo_members()
-- Not used with string-input-visitor.
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Message-Id: <20181121164421.20780-7-david@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Test that very big/small values are not accepted and that ranges with
only one element work. Also test that ranges are ascending and cannot
have more than 65536 elements.

Rename expect4 to expect5, as we will be moving that to a separate ulist
test after the rework.
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Message-Id: <20181121164421.20780-6-david@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Let's use the new function. Just as current behavior, we have to
consume the whole string (now it's just way clearer what's going on).
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Message-Id: <20181121164421.20780-5-david@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

The string-input-visitor happily accepts NaN and infinities when parsing
numbers (doubles). They shouldn't. Fix that.

Also, add two test cases, testing if "NaN" and "inf" is properly
rejected.
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Message-Id: <20181121164421.20780-4-david@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

qemu_strtosz() & friends reject NaNs, but happily accept infinities.
They shouldn't. Fix that.

The fix makes use of qemu_strtod_finite(). To avoid ugly casts,
change the @end parameter of qemu_strtosz() & friends from char **
to const char **.

Also, add two test cases, testing that "inf" and "NaN" are properly
rejected. While at it, also fixup the function documentation.
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Message-Id: <20181121164421.20780-3-david@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Let's provide a wrapper for strtod().
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Message-Id: <20181121164421.20780-2-david@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Monitor patches for 2018-12-12

# gpg: Signature made Wed 12 Dec 2018 10:08:15 GMT
# gpg:                using RSA key 3870B400EB918653
# gpg: Good signature from "Markus Armbruster <armbru@redhat.com>"
# gpg:                 aka "Markus Armbruster <armbru@pond.sub.org>"
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867  4E5F 3870 B400 EB91 8653

* remotes/armbru/tags/pull-monitor-2018-12-12:
  tests: add oob functional test for test-qmp-cmds
  Revert "tests: Add parameter to qtest_init_without_qmp_handshake"
  monitor: Remove "x-oob", offer capability "oob" unconditionally
  monitor: Suspend monitor instead dropping commands
  monitor: avoid potential dead-lock when cleaning up
  monitor: prevent inserting new monitors after cleanup
  colo: check chardev can switch context
  monitor: check if chardev can switch gcontext for OOB
  char: add a QEMU_CHAR_FEATURE_GCONTEXT flag
  monitor: accept chardev input from iothread
  monitor: inline ambiguous helper functions
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

s390x patches for 4.0:
- add 4.0 machine type
- various fixes and small changes

# gpg: Signature made Wed 12 Dec 2018 09:52:04 GMT
# gpg:                using RSA key DECF6B93C6F02FAF
# gpg: Good signature from "Cornelia Huck <conny@cornelia-huck.de>"
# gpg:                 aka "Cornelia Huck <huckc@linux.vnet.ibm.com>"
# gpg:                 aka "Cornelia Huck <cornelia.huck@de.ibm.com>"
# gpg:                 aka "Cornelia Huck <cohuck@kernel.org>"
# gpg:                 aka "Cornelia Huck <cohuck@redhat.com>"
# Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0  18CE DECF 6B93 C6F0 2FAF

* remotes/cohuck/tags/s390x-20181212:
  hw/s390x/virtio-ccw.c: Don't take address of fields in packed structs
  vfio-ap: flag as compatible with balloon
  s390x/tod: Properly stop the KVM TOD while the guest is not running
  s390/MAINTAINERS: Add Halil as kvm and machine maintainer
  s390x: introduce 4.0 compat machine
  s390x/zpci: drop msix.available
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Pull request

Minor virtio-blk fixes.

# gpg: Signature made Wed 12 Dec 2018 09:50:17 GMT
# gpg:                using RSA key 9CA4ABB381AB73C8
# gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>"
# gpg:                 aka "Stefan Hajnoczi <stefanha@gmail.com>"
# Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35  775A 9CA4 ABB3 81AB 73C8

* remotes/stefanha/tags/block-pull-request:
  virtio-blk: fix comment for virtio_blk_rw_complete as nalloc is initially -1
  virtio-blk: rename iov to out_iov in virtio_blk_handle_request()
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Merge tpm 2018/12/04 v1

# gpg: Signature made Tue 04 Dec 2018 15:25:52 GMT
# gpg:                using RSA key 75AD65802A0B4211
# gpg: Good signature from "Stefan Berger <stefanb@linux.vnet.ibm.com>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: B818 B9CA DF90 89C2 D5CE  C66B 75AD 6580 2A0B 4211

* remotes/stefanberger/tags/pull-tpm-2018-12-04-1:
  tpm: Make sure the locality received from backend is valid
  tpm: Make sure new locality passed to tpm_tis_prep_abort() is valid
  tpm: Remove unused locty parameter from tpm_tis_abort()
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

x86 queue, 2018-12-11

* New CPU features: MOVDIRI, MOVDIR64B (Liu Jingqi);
  STIBP (Eduardo Habkost)
* Fix clang build warning (Peter Maydell)

# gpg: Signature made Tue 11 Dec 2018 20:52:56 GMT
# gpg:                using RSA key 2807936F984DC5A6
# gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>"
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF  D1AA 2807 936F 984D C5A6

* remotes/ehabkost/tags/x86-next-pull-request:
  i386: Add "stibp" flag name
  target/i386/kvm.c: Don't mark cpuid_data as QEMU_PACKED
  x86/cpu: Enable MOVDIR64B cpu feature
  x86/cpu: Enable MOVDIRI cpu feature
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Taking the address of a field in a packed struct is a bad idea, because
it might not be actually aligned enough for that pointer type (and
thus cause a crash on dereference on some host architectures). Newer
versions of clang warn about this. Avoid the bug by not using the
"modify in place" byte swapping functions.

Patch produced with scripts/coccinelle/inplace-byteswaps.cocci
(with a couple of long lines manually wrapped).
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-Id: <20181210120436.30522-1-peter.maydell@linaro.org>
Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: NHalil Pasic <pasic@linux.ibm.com>
Signed-off-by: NCornelia Huck <cohuck@redhat.com>

vfio-ap devices do not pin any pages in the host. Therefore, they
are compatible with memory ballooning.

Flag them as compatible, so both vfio-ap and a balloon can be
used simultaneously.

Cc: qemu-stable@nongnu.org
Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Tested-by: NTony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: NHalil Pasic <pasic@linux.ibm.com>
Signed-off-by: NCornelia Huck <cohuck@redhat.com>

Just like on other architectures, we should stop the clock while the guest
is not running. This is already properly done for TCG. Right now, doing an
offline migration (stop, migrate, cont) can easily trigger stalls in the
guest.

Even doing a
    (hmp) stop
    ... wait 2 minutes ...
    (hmp) cont
will already trigger stalls.

So whenever the guest stops, backup the KVM TOD. When continuing to run
the guest, restore the KVM TOD.

One special case is starting a simple VM: Reading the TOD from KVM to
stop it right away until the guest is actually started means that the
time of any simple VM will already differ to the host time. We can
simply leave the TOD running and the guest won't be able to recognize
it.

For migration, we actually want to keep the TOD stopped until really
starting the guest. To be able to catch most errors, we should however
try to set the TOD in addition to simply storing it. So we can still
catch basic migration problems.

If anything goes wrong while backing up/restoring the TOD, we have to
ignore it (but print a warning). This is then basically a fallback to
old behavior (TOD remains running).

I tested this very basically with an initrd:
    1. Start a simple VM. Observed that the TOD is kept running. Old
       behavior.
    2. Ordinary live migration. Observed that the TOD is temporarily
       stopped on the destination when setting the new value and
       correctly started when finally starting the guest.
    3. Offline live migration. (stop, migrate, cont). Observed that the
       TOD will be stopped on the source with the "stop" command. On the
       destination, the TOD is temporarily stopped when setting the new
       value and correctly started when finally starting the guest via
       "cont".
    4. Simple stop/cont correctly stops/starts the TOD. (multiple stops
       or conts in a row have no effect, so works as expected)

In the future, we might want to send the guest a special kind of time sync
interrupt under some conditions, so it can synchronize its tod to the
host tod. This is interesting for migration scenarios but also when we
get time sync interrupts ourselves. This however will most probably have
to be handled in KVM (e.g. when the tods differ too much) and is not
desired e.g. when debugging the guest (single stepping should not
result in permanent time syncs). I consider something like that an add-on
on top of this basic "don't break the guest" handling.
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Message-Id: <20181130094957.4121-1-david@redhat.com>
Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: NThomas Huth <thuth@redhat.com>
Signed-off-by: NCornelia Huck <cohuck@redhat.com>

Halil does more work in this area than I do right now. Lets add Halil.
Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20181204133802.100998-1-borntraeger@de.ibm.com>
Acked-by: NHalil Pasic <pasic@linux.ibm.com>
Signed-off-by: NCornelia Huck <cohuck@redhat.com>

Reviewed-by: NDavid Hildenbrand <david@redhat.com>
Signed-off-by: NCornelia Huck <cohuck@redhat.com>

I fail to see why this is useful as we require MSIX always and
completely fail adding a device.
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Message-Id: <20181105110313.29312-2-david@redhat.com>
Fixes: 4f6482bfReviewed-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NCollin Walling <walling@linux.ibm.com>
Signed-off-by: NCornelia Huck <cohuck@redhat.com>

Straightforward test just to let the test-qmp-cmds be complete.
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NPeter Xu <peterx@redhat.com>
Message-Id: <20181009062718.1914-6-peterx@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

This reverts commit ddee57e0.

Meanwhile, revert one line from fa198ad9 to make sure
qtest_init_without_qmp_handshake() will only pass in one parameter.
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NPeter Xu <peterx@redhat.com>
Message-Id: <20181009062718.1914-5-peterx@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Out-of-band command execution was introduced in commit cf869d53.
Unfortunately, we ran into a regression, and had to turn it into an
experimental option for 2.12 (commit be933ffc).

  http://lists.gnu.org/archive/html/qemu-devel/2018-03/msg06231.html

The regression has since been fixed (commit 951702f3 "monitor: bind
dispatch bh to iohandler context").  A thorough re-review of OOB
commands led to a few more issues, which have also been addressed.

This patch partly reverts be933ffc (monitor: new parameter "x-oob"),
and makes QMP monitors again offer capability "oob" whenever they can
provide it, i.e. when the monitor's character device is capable of
running in an I/O thread.

Some trivial touch-up in the test code is required to make sure qmp-test
won't break.
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NPeter Xu <peterx@redhat.com>
Message-Id: <20181009062718.1914-4-peterx@redhat.com>
[Conflict with "monitor: check if chardev can switch gcontext for OOB"
resolved, commit message updated]
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

The initial value of nalloc is -1, but not 1.
Signed-off-by: NDongli Zhang <dongli.zhang@oracle.com>
Reviewed-by: NLaurent Vivier <laurent@vivier.eu>
Message-id: 1541479952-32355-1-git-send-email-dongli.zhang@oracle.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>