summary refs log tree commit diff stats
path: root/scripts/tracetool/backend/ftrace.py (unfollow)
Commit message (Collapse)AuthorFilesLines
2021-01-04tracetool: add out_lineno and out_next_lineno to out()Stefan Hajnoczi1-1/+9
Make the output file line number and next line number available to out(). A later patch will use this to improve error messages. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20200827142915.108730-3-stefanha@redhat.com>
2021-01-04tracetool: add output filename command-line argumentStefan Hajnoczi5-24/+33
The tracetool.py script writes to stdout. This means the output filename is not available to the script. Add the output filename to the command-line so that the script has access to the filename. This also simplifies the tracetool.py invocation. It's no longer necessary to use meson's custom_build(capture : true) to save output. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20200827142915.108730-2-stefanha@redhat.com>
2021-01-04trace: Send "-d trace:help" output to stdoutDoug Evans2-7/+8
... for consistency with "-d help". Signed-off-by: Doug Evans <dje@google.com> Message-id: 20201125215245.3514695-1-dje@google.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-12-22tests/acceptance: Add a test with the Fedora 31 kernel and initrdThomas Huth1-0/+110
This initrd contains a virtio-net and a virtio-gpu kernel module, so we can check that we can set a MAC address for the network device and whether we can hot-plug and -unplug a virtio-crypto device. But the most interesting part is maybe that we can also successfully write some stuff into the emulated framebuffer of the virtio-gpu device and make sure that we can read back that data from a screenshot. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20201221143423.23607-1-thuth@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Tested-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-12-21s390x/pci: Fix memory_region_access_valid callMatthew Rosato1-4/+6
In pcistb_service_handler, a call is made to validate that the memory region can be accessed. However, the call is made using the entire length of the pcistb operation, which can be larger than the allowed memory access size (8). Since we already know that the provided buffer is a multiple of 8, fix the call to memory_region_access_valid to iterate over the memory region in the same way as the subsequent call to memory_region_dispatch_write. Fixes: 863f6f52b7 ("s390: implement pci instructions") Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Pierre Morel <pmorel@linux.ibm.com> Message-Id: <1608243397-29428-3-git-send-email-mjrosato@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-12-21s390x/pci: fix pcistb lengthMatthew Rosato1-2/+2
In pcistb_service_call, we are grabbing 8 bits from a guest register to indicate the length of the store operation -- but per the architecture the length is actually defined by 13 bits of the guest register. Fixes: 863f6f52b7 ("s390: implement pci instructions") Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <1608243397-29428-2-git-send-email-mjrosato@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-12-21tests/acceptance: Test the virtio-balloon device on s390xThomas Huth1-1/+11
Inflate the balloon and check whether the size of the memory changes. Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Tested-by: Willian Rampazzo <willianr@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20201215183623.110128-4-thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-12-21tests/acceptance: Test virtio-rng on s390 via /dev/hwrngThomas Huth1-2/+15
/dev/hwrng is only functional if virtio-rng is working right, so let's add a sanity check for this device node. Reviewed-by: Willian Rampazzo <willianr@redhat.com> Tested-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20201215183623.110128-3-thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-12-21tests/acceptance: Extract the code to clear dmesg and wait for CRW reportsThomas Huth1-13/+17
We will use this in more spots soon, so it's easier to put this into a separate function. Reviewed-by: Willian Rampazzo <willianr@redhat.com> Tested-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20201215183623.110128-2-thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-12-21tests/acceptance: test hot(un)plug of ccw devicesCornelia Huck1-0/+24
Hotplug a virtio-net-ccw device, and then hotunplug it again. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Tested-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Message-Id: <20201208122843.147186-1-cohuck@redhat.com>
2020-12-21target/s390x: Improve SUB LOGICAL WITH BORROWRichard Henderson5-73/+45
Now that SUB LOGICAL outputs borrow, we can use that as input directly. It also means we can re-use CC_OP_SUBU and produce an output borrow directly from SUB LOGICAL WITH BORROW. Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20201214221356.68039-5-richard.henderson@linaro.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-12-21target/s390x: Improve cc computation for SUBTRACT LOGICALRichard Henderson5-82/+43
The resulting cc is only dependent on the result and the carry-out. Carry-out and borrow-out are inverses, so are trivially converted. With tcg ops, it is easier to compute borrow-out than carry-out, so save result and borrow-out rather than the inputs. Borrow-out for 64-bit inputs is had via tcg_gen_sub2_i64 directly into cc_src. Borrow-out for 32-bit inputs is had via extraction from a normal 64-bit sub (with zero-extended inputs). Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20201214221356.68039-4-richard.henderson@linaro.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-12-21target/s390x: Improve ADD LOGICAL WITH CARRYRichard Henderson5-67/+34
Now that ADD LOGICAL outputs carry, we can use that as input directly. It also means we can re-use CC_OP_ADDU and produce an output carry directly from ADD LOGICAL WITH CARRY. Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20201214221356.68039-3-richard.henderson@linaro.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-12-21target/s390x: Improve cc computation for ADD LOGICALRichard Henderson5-74/+97
The resulting cc is only dependent on the result and the carry-out. So save those things rather than the inputs. Carry-out for 64-bit inputs is had via tcg_gen_add2_i64 directly into cc_src. Carry-out for 32-bit inputs is had via extraction from a normal 64-bit add (with zero-extended inputs). Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20201214221356.68039-2-richard.henderson@linaro.org> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-12-21qga/commands-posix: Send CCW address on s390x with the fsinfo dataThomas Huth2-1/+53
We need the CCW address on the libvirt side to correctly identify the disk, so add this information to the GuestDiskAddress on s390x. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Michael Roth <michael.roth@amd.com> Message-Id: <20201127082353.448251-1-thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-12-21MAINTAINERS: move my git tree to gitlabCornelia Huck1-5/+5
I push to gitlab anyway to get some CI coverage, so let's make it my primary tree to avoid workflow duplication. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Thomas Huth <thuth@redhat.com> Message-Id: <20201214132628.56019-1-cohuck@redhat.com>
2020-12-21s390x: pv: Fence additional unavailable SCLP facilities for PV guestsJanosch Frank2-3/+61
There's no VSIE support for a protected guest, so let's better not advertise it and its support facilities. Fixes: c3347ed0d2ee ("s390x: protvirt: Support unpack facility") Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20201211105109.2913-1-frankja@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2020-12-19qobject: Make QString immutableMarkus Armbruster4-88/+4
The functions to modify a QString's string are all unused now. Drop them, and make the string immutable. Saves 16 bytes per QString on my system. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-21-armbru@redhat.com>
2020-12-19block: Use GString instead of QString to build filenamesMarkus Armbruster1-5/+6
QString supports modifying its string, but it's quite limited: you can only append. Just one caller remains: bdrv_parse_filename_strip_prefix() uses it just for building an initial string. Change it to do build the initial string with GString. This is another step towards making QString immutable. Cc: Kevin Wolf <kwolf@redhat.com> Cc: Max Reitz <mreitz@redhat.com> Cc: qemu-block@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-20-armbru@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2020-12-19keyval: Use GString to accumulate value stringsMarkus Armbruster1-5/+6
QString supports modifying its string, but it's quite limited: you can only append. The remaining callers use it for building an initial string, never for modifying it later. Change keyval_parse_one() to do build the initial string with GString. This is another step towards making QString immutable. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-19-armbru@redhat.com>
2020-12-19json: Use GString instead of QString to accumulate stringsMarkus Armbruster1-15/+15
QString supports modifying its string, but it's quite limited: you can only append. The remaining callers use it for building an initial string, never for modifying it later. Change parse_string() to do build the initial string with GString. This is another step towards making QString immutable. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-18-armbru@redhat.com>
2020-12-19migration: Replace migration's JSON writer by the general oneMarkus Armbruster29-253/+114
Commit 8118f0950f "migration: Append JSON description of migration stream" needs a JSON writer. The existing qobject_to_json() wasn't a good fit, because it requires building a QObject to convert. Instead, migration got its very own JSON writer, in commit 190c882ce2 "QJSON: Add JSON writer". It tacitly limits numbers to int64_t, and strings contents to characters that don't need escaping, unlike qobject_to_json(). The previous commit factored the JSON writer out of qobject_to_json(). Replace migration's JSON writer by it. Cc: Juan Quintela <quintela@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-17-armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-12-19qobject: Factor JSON writer out of qobject_to_json()Markus Armbruster5-100/+317
We have two JSON writers written in C: qobject/qjson.c provides qobject_to_json(), and migration/qjson.c provides a more low level imperative interface. They don't share code. The latter tacitly limits numbers to int64_t, and strings contents to characters that don't need escaping. Factor out qobject_to_json()'s JSON writer as qobject/json-writer.c. Straightforward, except for numbers: since the writer is to be independent of QObject, it can't use qnum_to_string(). Open-code it instead. This is actually an improvement of sorts, because it liberates qnum_to_string() from JSON's needs: its JSON-related FIXMEs move to the JSON writer, where they belong. The next commit will replace migration/qjson.c. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-16-armbru@redhat.com>
2020-12-19qobject: Factor quoted_str() out of to_json()Markus Armbruster1-56/+54
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-15-armbru@redhat.com>
2020-12-19qobject: Drop qstring_get_try_str()Markus Armbruster3-17/+5
No users left outside tests/, and the ones in tests/ can just as well use qstring_get_str(). Do that, and drop the function. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-14-armbru@redhat.com>
2020-12-19qobject: Drop qobject_get_try_str()Markus Armbruster2-12/+0
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-13-armbru@redhat.com>
2020-12-19Revert "qobject: let object_property_get_str() use new API"Markus Armbruster1-3/+6
Commit aafb21a0b9 "qobject: let object_property_get_str() use new API" isn't much of a simplification. Not worth having object_property_get_str() differ from the other object_property_get_FOO(). Revert. This reverts commit aafb21a0b9cea5fa0fe52e68111bb6bd13837a02. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Daniel P. Berrangé <berrange@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-12-armbru@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
2020-12-19block: Avoid qobject_get_try_str()Markus Armbruster1-3/+3
I'm about to remove qobject_get_try_str(). Use qstring_get_str() instead. Safe because the argument is known to be a QString here. Cc: Kevin Wolf <kwolf@redhat.com> Cc: Max Reitz <mreitz@redhat.com> Cc: qemu-block@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-11-armbru@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2020-12-19qmp: Fix tracing of non-string command IDsMarkus Armbruster1-12/+18
Tracepoints monitor_qmp_cmd_in_band and monitor_qmp_cmd_out_of_band (commit cf869d5317 "qmp: support out-of-band (oob) execution") treat non-string "id" like absent "id". Fix that. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-10-armbru@redhat.com>
2020-12-19qobject: Move internals to qobject-internal.hMarkus Armbruster15-21/+47
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-9-armbru@redhat.com>
2020-12-19hw/rdma: Replace QList by GQueueMarkus Armbruster4-26/+30
RdmaProtectedQList provides a thread-safe queue of int64_t on top of a QList. rdma_protected_qlist_destroy() calls qlist_destroy_obj() directly. qlist_destroy_obj() is actually for use by qobject_destroy() only. The next commit will make that obvious. The minimal fix would be calling qobject_unref() instead. But QList is actually a bad fit here. It's designed for representing JSON arrays. We're better off with a GQueue here. Replace. Cc: Yuval Shaia <yuval.shaia.ml@gmail.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-8-armbru@redhat.com>
2020-12-19Revert "qstring: add qstring_free()"Markus Armbruster2-23/+5
This reverts commit 164c374b75f87c6765a705c4418ab7005a2d356f. A free function for a reference-counted object is in bad taste. Fortunately, this one is now also unused. Drop it. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-7-armbru@redhat.com>
2020-12-19qobject: Change qobject_to_json()'s value to GStringMarkus Armbruster12-93/+79
qobject_to_json() and qobject_to_json_pretty() build a GString, then covert it to QString. Just one of the callers actually needs a QString: qemu_rbd_parse_filename(). A few others need a string they can modify: qmp_send_response(), qga's send_response(), to_json_str(), and qmp_fd_vsend_fds(). The remainder just need a string. Change qobject_to_json() and qobject_to_json_pretty() to return the GString. qemu_rbd_parse_filename() now has to convert to QString. All others save a QString temporary. to_json_str() actually becomes a bit simpler, because GString provides more convenient modification functions. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-6-armbru@redhat.com>
2020-12-19qobject: Use GString instead of QString to accumulate JSONMarkus Armbruster3-47/+58
QString supports modifying its string, but it's quite limited: you can only append. The remaining callers use it for building an initial string, never for modifying it later. Use of GString for building the initial string is actually more convenient here. Change qobject_to_json() & friends to do that. Once all such uses are replaced this way, QString can become immutable. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-5-armbru@redhat.com>
2020-12-19qobject: Make qobject_to_json_pretty() take a pretty argumentMarkus Armbruster6-19/+13
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-4-armbru@redhat.com>
2020-12-19monitor: Use GString instead of QString for output bufferMarkus Armbruster3-14/+10
GString has a richer set of string operations than QString. It should be preferred to QString except where we need a QObject or reference counting. We don't here. Switch to GString, and put its richer interface to use. Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-3-armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-12-19hmp: Simplify how qmp_human_monitor_command() gets outputMarkus Armbruster1-5/+1
Commit 48c043d0d1 "hmp: human-monitor-command: stop using the Memory chardev driver" left us "if string is non-empty, duplicate it, else duplicate the empty string". Meh. Duplicate it unconditionally. Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-2-armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-12-19test-visitor-serialization: Clean up test_primitives()Markus Armbruster1-7/+37
test_primitives() uses union member intmax_t max to compare the integer members. Unspecified behavior. Has worked fine for many years, though. Clean it up. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201210161452.2813491-11-armbru@redhat.com>
2020-12-19test-visitor-serialization: Drop insufficient precision workaroundMarkus Armbruster1-16/+2
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201210161452.2813491-10-armbru@redhat.com>
2020-12-19string-output-visitor: Fix to use sufficient precisionMarkus Armbruster2-2/+2
The string output visitor should serialize numbers so that the string input visitor deserializes them back to the same number. It fails to do so. print_type_number() uses format %f. This is prone to nasty rounding errors. For instance, numbers between 0 and 0.0000005 get flushed to zero. We currently use this visitor only for HMP info migrate, info network, info qtree, and info memdev. No double values occur there as far as I can tell. Fix anyway by formatting with %.17g. 17 decimal digits always suffice for IEEE double. See also recent commit "qobject: Fix qnum_to_string() to use sufficient precision". Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201210161452.2813491-9-armbru@redhat.com>
2020-12-19test-string-output-visitor: Cover "unround" numberMarkus Armbruster1-2/+2
This demonstrates rounding error due to insufficient precision: double 3.1415926535897932 gets converted to JSON 3.141593. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201210161452.2813491-8-armbru@redhat.com>
2020-12-19qobject: Fix qnum_to_string() to use sufficient precisionMarkus Armbruster3-27/+9
We should serialize numbers to JSON so that they deserialize back to the same number. We fail to do so. The culprit is qnum_to_string(): it uses format %f with trailing '0' trimmed. Results in pretty output for "nice" numbers, but is prone to nasty rounding errors. For instance, numbers between 0 and 0.0000005 get flushed to zero. Where exactly the incorrect rounding can bite is tiresome to gauge. Here's my take. * In QMP output, type 'number': - query-blockstats value avg_rd_queue_depth - QMP query-migrate values mbps, cache-miss-rate, encoding-rate, busy-rate, compression-rate. Relatively harmless, I guess. * In tracing QMP input. Harmless. * In qemu-ga output, type 'number': guest-get-users value login-time. Harmless. * In output of HMP qom-get. Harmless. Not affected, because double values don't actually occur there (I think): * QMP output, type 'any': * qom-get value * qom-list, qom-list-properties value default-value * query-cpu-model-comparison, query-cpu-model-baseline, query-cpu-model-expansion value props. * qemu-img --output json output. * "json:" pseudo-filenames generated by bdrv_refresh_filename(). * The rbd block driver's "=keyvalue-pairs" hack. * In -object help on property default values. Aside: use of JSON feels inappropriate here. * Output of HMP qom-get. * Argument conversion to QemuOpts for qdev_device_add() and HMP with qemu_opts_from_qdict() QMP and HMP device_add, virtio-net failover primary creation, xen-usb "usb-host" creation, HMP netdev_add, object_add. * The uses of qobject_input_visitor_new_flat_confused() As far as I can tell, none of the visited types contain double values. * Dumping ImageInfoSpecific with dump_qobject() Fix by formatting with %.17g. 17 decimal digits always suffice for IEEE double. The change to expected test output illustrates the effect: the rounding errors are gone, but some seemingly "nice" numbers now get converted to not so nice strings, e.g. 0.42 to "0.41999999999999998". This is because 0.42 is not representable exactly in double. It's more accurate in this example than strictly necessary, though. If ugly accuracy bothers us, we can we can try using the least number of digits that still converts back to the same double. In this example, "0.42" would do. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201210161452.2813491-7-armbru@redhat.com>
2020-12-19tests/check-qnum: Cover qnum_to_string() for "unround" argumentMarkus Armbruster1-0/+6
qnum_to_string() has a FIXME comment about rounding errors due to insufficient precision. Cover it: 2.718281828459045 gets converted to "2.718282". The next commit will fix it. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201210161452.2813491-6-armbru@redhat.com>
2020-12-19tests/check-qjson: Replace redundant large_number()Markus Armbruster1-44/+3
Move one of large_number()'s three checks to uint_number(), and the other two to float_number(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201210161452.2813491-5-armbru@redhat.com>
2020-12-19tests/check-qjson: Cover number 2^63Markus Armbruster1-2/+39
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201210161452.2813491-4-armbru@redhat.com>
2020-12-19tests/check-qjson: Examine QNum more thoroughlyMarkus Armbruster1-3/+16
simple_number() checks only qnum_get_try_int(). Also check qnum_get_try_uint() and qnum_get_double(). float_number() checks only qnum_get_double(). Also check qnum_get_try_int() and qnum_get_try_uint(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201210161452.2813491-3-armbru@redhat.com>
2020-12-19tests/check-qjson: Don't skip funny QNumber to JSON conversionsMarkus Armbruster1-30/+25
simple_number() and float_number() convert from JSON to QNumber and back. simple_number() tests "-0", but skips the conversion back to JSON, because it yields "0", not "-0". Works as intended, so better cover it: don't skip, but expect the funny result. float_number() tests "-32.20e-10", but skips the conversion back to JSON, because it yields "-0". This is a known bug in qnum_to_string(), marked FIXME there. Cover the bug: don't skip, but expect the funny result. While there, switch from g_assert() to g_assert_cmpstr() & friends for friendlier test failures. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201210161452.2813491-2-armbru@redhat.com>
2020-12-19qapi: Use QAPI_LIST_PREPEND() where possibleEric Blake32-424/+161
Anywhere we create a list of just one item or by prepending items (typically because order doesn't matter), we can use QAPI_LIST_PREPEND(). But places where we must keep the list in order by appending remain open-coded until later patches. Note that as a side effect, this also performs a cleanup of two minor issues in qga/commands-posix.c: the old code was performing new = g_malloc0(sizeof(*ret)); which 1) is confusing because you have to verify whether 'new' and 'ret' are variables with the same type, and 2) would conflict with C++ compilation (not an actual problem for this file, but makes copy-and-paste harder). Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20201113011340.463563-5-eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> [Straightforward conflicts due to commit a8aa94b5f8 "qga: update schema for guest-get-disks 'dependents' field" and commit a10b453a52 "target/mips: Move mips_cpu_add_definition() from helper.c to cpu.c" resolved. Commit message tweaked.] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2020-12-19migration: Refactor migrate_cap_addEric Blake1-13/+9
Instead of taking a list parameter and returning a new head at a distance, just return the new item for the caller to insert into a list via QAPI_LIST_PREPEND. Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20201113011340.463563-4-eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2020-12-19rocker: Revamp fp_port_get_infoEric Blake3-15/+12
Instead of modifying the value member of a list element passed as a parameter, and open-coding the manipulation of that list, it's nicer to just return a freshly allocated value to be prepended to a list using QAPI_LIST_PREPEND. Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20201113011340.463563-3-eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>