aboutsummaryrefslogtreecommitdiff
path: root/tests
AgeCommit message (Collapse)Author
2020-12-19qobject: Drop qstring_get_try_str()Markus Armbruster
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: Change qobject_to_json()'s value to GStringMarkus Armbruster
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: Make qobject_to_json_pretty() take a pretty argumentMarkus Armbruster
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201211171152.146877-4-armbru@redhat.com>
2020-12-19test-visitor-serialization: Clean up test_primitives()Markus Armbruster
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 Armbruster
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 Armbruster
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 Armbruster
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 Armbruster
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 Armbruster
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 Armbruster
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 Armbruster
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 Armbruster
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 Armbruster
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 Blake
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-18iotests: Fix _send_qemu_cmd with bash 5.1Max Reitz
With bash 5.1, the output of the following script changes: a=("double space") a=${a[@]:0:1} echo "$a" from "double space" to "double space", i.e. all white space is preserved as-is. This is probably what we actually want here (judging from the "...to accommodate pathnames with spaces" comment), but before 5.1, we would have to quote the ${} slice to get the same behavior. In any case, without quoting, the reference output of many iotests is different between bash 5.1 and pre-5.1, which is not very good. The output of 5.1 is what we want, so whatever we do to get pre-5.1 to the same result, it means we have to fix the reference output of basically all tests that invoke _send_qemu_cmd (except the ones that only use single spaces in the commands they invoke). Instead of quoting the ${} slice (cmd="${$@: 1:...}"), we can also just not use array slicing and replace the whole thing with a simple "cmd=$1; shift", which works because all callers quote the whole $cmd argument anyway. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20201217153803.101231-3-mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2020-12-18iotests/102: Pass $QEMU_HANDLE to _send_qemu_cmdMax Reitz
The first parameter passed to _send_qemu_cmd is supposed to be the $QEMU_HANDLE. 102 does not do so here, fix it. As a result, the output changes: Now we see the prompt this command is supposedly waiting for before the resize message - as it should be. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20201217153803.101231-2-mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2020-12-18quorum: Implement bdrv_co_pwrite_zeroes()Alberto Garcia
This simply calls bdrv_co_pwrite_zeroes() in all children. bs->supported_zero_flags is also set to the flags that are supported by all children. Signed-off-by: Alberto Garcia <berto@igalia.com> Message-Id: <2f09c842781fe336b4c2e40036bba577b7430190.1605286097.git.berto@igalia.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-12-18quorum: Implement bdrv_co_block_status()Alberto Garcia
The quorum driver does not implement bdrv_co_block_status() and because of that it always reports to contain data even if all its children are known to be empty. One consequence of this is that if we for example create a quorum with a size of 10GB and we mirror it to a new image the operation will write 10GB of actual zeroes to the destination image wasting a lot of time and disk space. Since a quorum has an arbitrary number of children of potentially different formats there is no way to report all possible allocation status flags in a way that makes sense, so this implementation only reports when a given region is known to contain zeroes (BDRV_BLOCK_ZERO) or not (BDRV_BLOCK_DATA). If all children agree that a region contains zeroes then we can return BDRV_BLOCK_ZERO using the smallest size reported by the children (because all agree that a region of at least that size contains zeroes). If at least one child disagrees we have to return BDRV_BLOCK_DATA. In this case we use the largest of the sizes reported by the children that didn't return BDRV_BLOCK_ZERO (because we know that there won't be an agreement for at least that size). Signed-off-by: Alberto Garcia <berto@igalia.com> Tested-by: Tao Xu <tao3.xu@intel.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-Id: <db83149afcf0f793effc8878089d29af4c46ffe1.1605286097.git.berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-12-18iotests: add 298 to test new preallocate filter driverVladimir Sementsov-Ogievskiy
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20201021145859.11201-13-vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-12-18iotests.py: execute_setup_common(): add required_fmts argumentVladimir Sementsov-Ogievskiy
Add a parameter to skip test if some needed additional formats are not supported (for example filter drivers). Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20201021145859.11201-12-vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-12-18iotests: qemu_io_silent: support --image-optsVladimir Sementsov-Ogievskiy
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-Id: <20201021145859.11201-11-vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-12-18tests/acceptance: Bump avocado requirements to 83.0Wainer dos Santos Moschetta
To use Avocado's testlogs plug-in on CI it is required to use its 83.0 or greater version. Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Message-Id: <20201211183827.915232-2-wainersm@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-12-18fuzz: fix the generic-fuzz-floppy configAlexander Bulekov
On the pc-i440fx machine, the floppy drive relies on the i8257 DMA controller. Add this device to the floppy fuzzer config, and silence the warning about a missing format specifier for the null-co:// drive. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20201216203328.41112-1-alxndr@bu.edu> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-12-18fuzz: Add more i386 configurations for fuzzingAlexander Bulekov
This adds configurations for fuzzing the following devices on oss-fuzz: * vmxnet3 CC: Dmitry Fleytman <dmitry.fleytman@gmail.com> * ne2k * pcnet * rtl8139 CC: Jason Wang <jasowang@redhat.com> * eepro100 CC: Stefan Weil <sw@weilnetz.de> * sdhci CC: Philippe Mathieu-Daudé <f4bug@amsat.org> * ehci * ohci * ac97 * cs4231a * es1370 * sb16 CC: Gerd Hoffmann <kraxel@redhat.com> * megasas CC: Hannes Reinecke <hare@suse.com> * parallel CC: Michael S. Tsirkin <mst@redhat.com> CC: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20201123184352.242907-1-alxndr@bu.edu> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-12-18iotests:172: use _filter_qom_pathVladimir Sementsov-Ogievskiy
device[NUMBER] thing in QOM path is not stable and tracking it during code modifications is not fun. Let's filter it like it's already done in iotest 186. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20201216095205.526235-3-vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-12-18iotests: make _filter_qom_path more strictVladimir Sementsov-Ogievskiy
According to original commit, that added this filter (627f607e3dddb2), the problematic thing in qom path is device[NUMBER], not the whole path. Seems that tracking the other parts of the path in iotest output is not bad. Let's make _filter_qom_path stricter. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20201216095205.526235-2-vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-12-18iotests/210: Fix reference outputMax Reitz
Commit 8b1170012b1 has added a global maximum disk length for the block layer, so the error message when creating an overly large disk has changed. Fixes: 8b1170012b1de6649c66ac1887f4df7e312abf3b ("block: introduce BDRV_MAX_LENGTH") Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20201214175158.299919-1-mreitz@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-12-18tests/fp: Do not emit implicit-fallthrough warnings in the softfloat testsThomas Huth
The softfloat tests are external repositories, so we do not care about implicit fallthrough warnings in this code. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Chen Qun <kuhn.chenqun@huawei.com> Message-Id: <20201211152426.350966-12-thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-12-15tests: remove GCC < 4 fallbacksMarc-André Lureau
Since commit efc6c07 ("configure: Add a test for the minimum compiler version"), QEMU explicitely depends on GCC >= 4.8. (clang >= 3.4 advertizes itself as GCC >= 4.2 compatible) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20201210134752.780923-6-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-12-15Remove the deprecated -realtime optionThomas Huth
It has been marked as deprecated since QEMU v4.2, replaced by the -overcommit option. Time to remove it now. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20201210155808.233895-4-thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-12-15memory: clamp cached translation in case it points to an MMIO regionPaolo Bonzini
In using the address_space_translate_internal API, address_space_cache_init forgot one piece of advice that can be found in the code for address_space_translate_internal: /* MMIO registers can be expected to perform full-width accesses based only * on their address, without considering adjacent registers that could * decode to completely different MemoryRegions. When such registers * exist (e.g. I/O ports 0xcf8 and 0xcf9 on most PC chipsets), MMIO * regions overlap wildly. For this reason we cannot clamp the accesses * here. * * If the length is small (as is the case for address_space_ldl/stl), * everything works fine. If the incoming length is large, however, * the caller really has to do the clamping through memory_access_size. */ address_space_cache_init is exactly one such case where "the incoming length is large", therefore we need to clamp the resulting length---not to memory_access_size though, since we are not doing an access yet, but to the size of the resulting section. This ensures that subsequent accesses to the cached MemoryRegionSection will be in range. With this patch, the enclosed testcase notices that the used ring does not fit into the MSI-X table and prints a "qemu-system-x86_64: Cannot map used" error. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-12-15qtest/pvpanic: Test panic option that allows VM to continueAlejandro Jimenez
Test the scenario where the -action panic=none parameter is used to signal that the VM must continue executing after a guest panic occurs. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Message-Id: <1607705564-26264-5-git-send-email-alejandro.j.jimenez@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-12-15remove preconfig statePaolo Bonzini
The preconfig state is only used if -incoming is not specified, which makes the RunState state machine more tricky than it need be. However there is already an equivalent condition which works even with -incoming, namely qdev_hotplug. Use it instead of a separate runstate. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-12-14tests/tcg/multiarch/Makefile.target: Disable run-gdbstub-sha1 testPeter Maydell
Disable the run-gdbstub-sha1 test: it provokes an internal error assertion failure in Ubuntu gdb 8.1.1-0ubuntu1 (Ubuntu gdb 8.1-0ubuntu3.2 also has this assert but we were previously skipping this test because it doesn't support connection over local domain sockets) : timeout 60 /home/petmay01/linaro/qemu-for-merges/tests/guest-debug/run-test.py --gdb /usr/bin/gdb-multiar /build/gdb-veKdC1/gdb-8.1.1/gdb/regcache.c:122: internal-error: void* init_regcache_descr(gdbarch*): Asser A problem internal to GDB has been detected, further debugging may prove unreliable. This is a bug, please report it. For instructions, see: <http://www.gnu.org/software/gdb/bugs/>. Aborted (core dumped) /home/petmay01/linaro/qemu-for-merges/tests/tcg/multiarch/Makefile.target:51: recipe for target 'run-gdbst Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20201214133702.24088-1-peter.maydell@linaro.org
2020-12-12Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into stagingPeter Maydell
Block layer patches: - Support for FUSE exports - Fix deadlock in bdrv_co_yield_to_drain() - Use lock guard macros - Some preparational patches for 64 bit block layer - file-posix: Fix request extension to INT64_MAX in raw_do_pwrite_zeroes() # gpg: Signature made Fri 11 Dec 2020 17:06:19 GMT # gpg: using RSA key DC3DEB159A9AF95D3D7456FE7F09B272C88F2FD6 # gpg: issuer "kwolf@redhat.com" # gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full] # Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6 * remotes/kevin/tags/for-upstream: (34 commits) block: Fix deadlock in bdrv_co_yield_to_drain() block: Fix locking in qmp_block_resize() block: Simplify qmp_block_resize() error paths block: introduce BDRV_MAX_LENGTH block/io: bdrv_check_byte_request(): drop bdrv_is_inserted() block/io: bdrv_refresh_limits(): use ERRP_GUARD block/file-posix: fix workaround in raw_do_pwrite_zeroes() can-host: Fix crash when 'canbus' property is not set iotests/221: Discard image before qemu-img map file-posix: check the use_lock before setting the file lock iotests/308: Add test for FUSE exports iotests: Enable fuse for many tests iotests: Allow testing FUSE exports iotests: Give access to the qemu-storage-daemon storage-daemon: Call bdrv_close_all() on exit iotests/287: Clean up subshell test image iotests: Let _make_test_img guess $TEST_IMG_FILE iotests: Restrict some Python tests to file iotests/091: Use _cleanup_qemu instad of "wait" iotests: Derive image names from $TEST_IMG ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-12-11Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20201211' into stagingPeter Maydell
First set of 6.0 patches for s390x: - acceptance test for device detection - bugfixes # gpg: Signature made Fri 11 Dec 2020 12:21:45 GMT # gpg: using RSA key C3D0D66DC3624FF6A8C018CEDECF6B93C6F02FAF # gpg: issuer "cohuck@redhat.com" # gpg: Good signature from "Cornelia Huck <conny@cornelia-huck.de>" [unknown] # gpg: aka "Cornelia Huck <huckc@linux.vnet.ibm.com>" [full] # gpg: aka "Cornelia Huck <cornelia.huck@de.ibm.com>" [full] # gpg: aka "Cornelia Huck <cohuck@kernel.org>" [unknown] # gpg: aka "Cornelia Huck <cohuck@redhat.com>" [unknown] # Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0 18CE DECF 6B93 C6F0 2FAF * remotes/cohuck/tags/s390x-20201211: s390x/cpu: Use timer_free() in the finalize function to avoid memleaks tests/acceptance: test s390x zpci fid propagation tests/acceptance: verify s390x device detection tests/acceptance: test virtio-ccw revision handling tests/acceptance: add a test for devices on s390x hw/watchdog/wdt_diag288: Remove unnecessary includes Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-12-11block: introduce BDRV_MAX_LENGTHVladimir Sementsov-Ogievskiy
We are going to modify block layer to work with 64bit requests. And first step is moving to int64_t type for both offset and bytes arguments in all block request related functions. It's mostly safe (when widening signed or unsigned int to int64_t), but switching from uint64_t is questionable. So, let's first establish the set of requests we want to work with. First signed int64_t should be enough, as off_t is signed anyway. Then, obviously offset + bytes should not overflow. And most interesting: (offset + bytes) being aligned up should not overflow as well. Aligned to what alignment? First thing that comes in mind is bs->bl.request_alignment, as we align up request to this alignment. But there is another thing: look at bdrv_mark_request_serialising(). It aligns request up to some given alignment. And this parameter may be bdrv_get_cluster_size(), which is often a lot greater than bs->bl.request_alignment. Note also, that bdrv_mark_request_serialising() uses signed int64_t for calculations. So, actually, we already depend on some restrictions. Happily, bdrv_get_cluster_size() returns int and bs->bl.request_alignment has 32bit unsigned type, but defined to be a power of 2 less than INT_MAX. So, we may establish, that INT_MAX is absolute maximum for any kind of alignment that may occur with the request. Note, that bdrv_get_cluster_size() is not documented to return power of 2, still bdrv_mark_request_serialising() behaves like it is. Also, backup uses bdi.cluster_size and is not prepared to it not being power of 2. So, let's establish that Qemu supports only power-of-2 clusters and alignments. So, alignment can't be greater than 2^30. Finally to be safe with calculations, to not calculate different maximums for different nodes (depending on cluster size and request_alignment), let's simply set QEMU_ALIGN_DOWN(INT64_MAX, 2^30) as absolute maximum bytes length for Qemu. Actually, it's not much less than INT64_MAX. OK, then, let's apply it to block/io. Let's consider all block/io entry points of offset/bytes: 4 bytes/offset interface functions: bdrv_co_preadv_part(), bdrv_co_pwritev_part(), bdrv_co_copy_range_internal() and bdrv_co_pdiscard() and we check them all with bdrv_check_request(). We also have one entry point with only offset: bdrv_co_truncate(). Check the offset. And one public structure: BdrvTrackedRequest. Happily, it has only three external users: file-posix.c: adopted by this patch write-threshold.c: only read fields test-write-threshold.c: sets obviously small constant values Better is to make the structure private and add corresponding interfaces.. Still it's not obvious what kind of interface is needed for file-posix.c. Let's keep it public but add corresponding assertions. After this patch we'll convert functions in block/io.c to int64_t bytes and offset parameters. We can assume that offset/bytes pair always satisfy new restrictions, and make corresponding assertions where needed. If we reach some offset/bytes point in block/io.c missing bdrv_check_request() it is considered a bug. As well, if block/io.c modifies a offset/bytes request, expanding it more then aligning up to request_alignment, it's a bug too. For all io requests except for discard we keep for now old restriction of 32bit request length. iotest 206 output error message changed, as now test disk size is larger than new limit. Add one more test case with new maximum disk size to cover too-big-L1 case. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20201203222713.13507-5-vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-12-11iotests/221: Discard image before qemu-img mapMax Reitz
See the new comment for why this should be done. I do not have a reproducer on master, but when using FUSE block exports, this test breaks depending on the underlying filesystem (for me, it works on tmpfs, but fails on xfs, because the block allocated by file-posix has 16 kB there instead of 4 kB). Suggested-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20201207152245.66987-1-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-12-11iotests/308: Add test for FUSE exportsMax Reitz
We have good coverage of the normal I/O paths now, but what remains is a test that tests some more special cases: Exporting an image on itself (thus turning a formatted image into a raw one), some error cases, and non-writable and non-growable exports. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20201027190600.192171-21-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-12-11iotests: Enable fuse for many testsMax Reitz
Many tests (that do not support generic protocols) can run just fine with FUSE-exported images, so allow them to. Note that this is no attempt at being definitely complete. There are some tests that might be modified to run on FUSE, but this patch still skips them. This patch only tries to pick the rather low-hanging fruits. Note that 221 and 250 only pass when .lseek is correctly implemented, which is only possible with a libfuse that is 3.8 or newer. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20201027190600.192171-20-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-12-11iotests: Allow testing FUSE exportsMax Reitz
This pretends FUSE exports are a kind of protocol. As such, they are always tested under the format node. This is probably the best way to test them, actually, because this will generate more I/O load and more varied patterns. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20201027190600.192171-19-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-12-11iotests: Give access to the qemu-storage-daemonMax Reitz
Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20201027190600.192171-18-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-12-11iotests/287: Clean up subshell test imageMax Reitz
287 creates an image in a subshell (thanks to the pipe) to see whether that is possible with compression_type=zstd. If _make_test_img were to modify any global state, this global state would then be lost before we could cleanup the image. When using FUSE as the test protocol, this global state is important, so clean up the image before the state is lost. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20201027190600.192171-16-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-12-11iotests: Let _make_test_img guess $TEST_IMG_FILEMax Reitz
When most iotests want to create a test image that is named differently from the default $TEST_IMG, they do something like this: TEST_IMG="$TEST_IMG.base" _make_test_img $options This works fine with the "file" protocol, but not so much for anything else: _make_test_img tries to create an image under $TEST_IMG_FILE first, and only under $TEST_IMG if the former is not set; and on everything but "file", $TEST_IMG_FILE is set. There are two ways we can fix this: First, we could make all tests adjust not only TEST_IMG, but also TEST_IMG_FILE if that is present (e.g. with something like _set_test_img_suffix $suffix that would affect not only TEST_IMG but also TEST_IMG_FILE, if necessary). This is a pretty clean solution, and this is maybe what we should have done from the start. But it would also require changes to most existing bash tests. So the alternative is this: Let _make_test_img see whether $TEST_IMG_FILE still points to the original value. If so, it is possible that the caller has adjusted $TEST_IMG but not $TEST_IMG_FILE. In such a case, we can (for most protocols) derive the corresponding $TEST_IMG_FILE value from $TEST_IMG value and thus work around what technically is the caller misbehaving. This second solution is less clean, but it is robust against people keeping their old habit of adjusting TEST_IMG only, and requires much less changes. So this patch implements it. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20201027190600.192171-15-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-12-11iotests: Restrict some Python tests to fileMax Reitz
Most Python tests are restricted to the file protocol (without explicitly saying so), but these are the ones that would break ./check -fuse -qcow2. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20201027190600.192171-14-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-12-11iotests/091: Use _cleanup_qemu instad of "wait"Max Reitz
If the test environment has some other child processes running (like a storage daemon that provides a FUSE export), then "wait" will never finish. Use wait=yes _cleanup_qemu instead. (We need to discard the output so there is no change to the reference output.) Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20201027190600.192171-13-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-12-11iotests: Derive image names from $TEST_IMGMax Reitz
Avoid creating images with custom filenames in $TEST_DIR, because non-file protocols may want to keep $TEST_IMG (and all other test images) in some other directory. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20201027190600.192171-12-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-12-11iotests/046: Avoid renaming imagesMax Reitz
This generally does not work on non-file protocols. It is better to create the image with the final name from the start, and most tests do this already. Let 046 follow suit. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20201027190600.192171-11-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-12-11iotests: Use convert -n in some casesMax Reitz
qemu-img convert (without -n) can often be replaced by a combination of _make_test_img + qemu-img convert -n. Doing so allows converting to protocols that do not allow direct file creation, such as FUSE exports. The only problem is that for formats other than qcow2 and qed (qcow1 at least), this may lead to high disk usage for some reason, so we cannot do it everywhere. But we can do it in 028 and 089, so let us do that so they can run on FUSE exports. Also, in 028 this allows us to remove a 9-line comment that used to explain why we cannot safely filter drive-backup's image creation output. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20201027190600.192171-10-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-12-11iotests: Do not pipe _make_test_imgMax Reitz
Executing _make_test_img as part of a pipe will undo all variable changes it has done. As such, this could not work with FUSE (because we want to remember all of our exports and their qemu instances). Replace the pipe by a temporary file in 071 and 174 (the two tests that can run on FUSE). Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20201027190600.192171-9-mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-16 21:23:25 +0000