riscv/qemu - qemu - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
John Snow	7d8140595f	iotests: add script_initialize Like script_main, but doesn't require a single point of entry. Replace all existing initialization sections with this drop-in replacement. This brings debug support to all existing script-style iotests. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200331000014.11581-12-jsnow@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> [mreitz: Give 274 the same treatment] Signed-off-by: Max Reitz <mreitz@redhat.com>	6 years ago
Philippe Mathieu-Daudé	7c47752608	tests/qemu-iotests: Explicit usage of Python3 (scripts without __main__) Use the program search path to find the Python 3 interpreter. Patch created mechanically by running: $ sed -i "s,^#\!/usr/bin/\(env\ \)\?python$,#\!/usr/bin/env python3," \ $(git grep -lF '#!/usr/bin/env python' \ \| xargs grep -L 'if __name__.*__main__') Reported-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Suggested-by: Stefan Hajnoczi <stefanha@redhat.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200130163232.10446-11-philmd@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>	6 years ago
Sergio Lopez	2288ccfac9	blockdev: unify qmp_drive_backup and drive-backup transaction paths Issuing a drive-backup from qmp_drive_backup takes a slightly different path than when it's issued from a transaction. In the code, this is manifested as some redundancy between do_drive_backup() and drive_backup_prepare(). This change unifies both paths, merging do_drive_backup() and drive_backup_prepare(), and changing qmp_drive_backup() to create a transaction instead of calling do_backup_common() direcly. As a side-effect, now qmp_drive_backup() is executed inside a drained section, as it happens when creating a drive-backup transaction. This change is visible from the user's perspective, as the job gets paused and immediately resumed before starting the actual work. Also fix tests 141, 185 and 219 to cope with the extra JOB_STATUS_CHANGE lines. Signed-off-by: Sergio Lopez <slp@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>	6 years ago
Max Reitz	d9efe9384e	iotests: Fix intermittent failure in 219 In 219, we wait for the job to make progress before we emit its status. This makes the output reliable. We do not wait for any more progress if the job's current-progress already matches its total-progress. Unfortunately, there is a bug: Right after the job has been started, it's possible that total-progress is still 0. In that case, we may skip the first progress-making step and keep ending up 64 kB short. To fix that bug, we can simply wait for total-progress to reach 4 MB (the image size) after starting the job. Reported-by: Karen Mezick <kmezick@redhat.com> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1686651 Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20190516161114.27596-1-mreitz@redhat.com Reviewed-by: John Snow <jsnow@redhat.com> [mreitz: Adjusted commit message as per John's proposal] Signed-off-by: Max Reitz <mreitz@redhat.com>	7 years ago
Max Reitz	83f90b535a	iotests: Fix 219's timing 219 has two issues that may lead to sporadic failure, both of which are the result of issuing query-jobs too early after a job has been modified. This can then lead to different results based on whether the modification has taken effect already or not. First, query-jobs is issued right after the job has been created. Besides its current progress possibly being in any random state (which has already been taken care of), its total progress too is basically arbitrary, because the job may not yet have been able to determine it. This patch addresses this by just filtering the total progress, like what has been done for the current progress already. However, for more clarity, the filtering is changed to replace the values by a string 'FILTERED' instead of deleting them. Secondly, query-jobs is issued right after a job has been resumed. The job may or may not yet have had the time to actually perform any I/O, and thus its current progress may or may not have advanced. To make sure it has indeed advanced (which is what the reference output already assumes), keep querying it until it has. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20180606190628.8170-1-mreitz@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>	8 years ago
Kevin Wolf	bdebdc712b	qemu-iotests: Test job-* with block jobs This adds a test case that tests the new job-* QMP commands with mirror and backup block jobs. Signed-off-by: Kevin Wolf <kwolf@redhat.com>	8 years ago