From: Max Reitz <mreitz@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] iotests: Add test for dataplane mirroring
Date: Fri, 30 Jun 2017 04:44:45 +0200 [thread overview]
Message-ID: <bc6ec1d8-f94c-904a-ff38-7c0b886d5d7b@redhat.com> (raw)
In-Reply-To: <20170629101008.GB4618@noname.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 5438 bytes --]
On 2017-06-29 12:10, Kevin Wolf wrote:
> Am 29.06.2017 um 01:23 hat Max Reitz geschrieben:
>> Signed-off-by: Max Reitz <mreitz@redhat.com>
>> ---
>> Depends on Stefan's "virtio: use ioeventfd in TCG and qtest mode" series
>> to work at all, and on "mirror: Fix inconsistent backing AioContext for
>> after mirroring" (in my block branch) so it does not fail.
>> ---
>> tests/qemu-iotests/106 | 97 ++++++++++++++++++++++++++++++++++++++++++++++
>> tests/qemu-iotests/106.out | 14 +++++++
>
> Your initiative to fill up the numbering hole is laudable, but are you
> intentionally using 106 for multiple patches of yours? ;-)
Well, as I said, I'm fine with each new test having test number 001 and
then moving it when applying. O:-)
Wasn't intentional, but well, I find it easier to find free test numbers
when applying patches anyway...
In this case, though, since the other user of 106 is already fully
reviewed, it's probably better to move this out of the way.
>> tests/qemu-iotests/group | 1 +
>> 3 files changed, 112 insertions(+)
>> create mode 100755 tests/qemu-iotests/106
>> create mode 100644 tests/qemu-iotests/106.out
>>
>> diff --git a/tests/qemu-iotests/106 b/tests/qemu-iotests/106
>> new file mode 100755
>> index 0000000..ad438b5
>> --- /dev/null
>> +++ b/tests/qemu-iotests/106
>> @@ -0,0 +1,97 @@
>> +#!/bin/bash
>> +#
>> +# Test case for mirroring with dataplane
>> +#
>> +# Copyright (C) 2017 Red Hat, Inc.
>> +#
>> +# This program is free software; you can redistribute it and/or modify
>> +# it under the terms of the GNU General Public License as published by
>> +# the Free Software Foundation; either version 2 of the License, or
>> +# (at your option) any later version.
>> +#
>> +# This program is distributed in the hope that it will be useful,
>> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> +# GNU General Public License for more details.
>> +#
>> +# You should have received a copy of the GNU General Public License
>> +# along with this program. If not, see <http://www.gnu.org/licenses/>.
>> +#
>> +
>> +# creator
>> +owner=mreitz@redhat.com
>> +
>> +seq=$(basename $0)
>> +echo "QA output created by $seq"
>> +
>> +here=$PWD
>> +status=1 # failure is the default!
>> +
>> +_cleanup()
>> +{
>> + _cleanup_qemu
>> + _cleanup_test_img
>> + _rm_test_img "$TEST_IMG.overlay0"
>> + _rm_test_img "$TEST_IMG.overlay1"
>> +}
>> +trap "_cleanup; exit \$status" 0 1 2 3 15
>> +
>> +# get standard environment, filters and qemu instance handling
>> +. ./common.rc
>> +. ./common.filter
>> +. ./common.qemu
>> +
>> +_supported_fmt qcow2
>> +_supported_proto file
>> +_supported_os Linux
>> +
>> +IMG_SIZE=64K
>> +
>> +_make_test_img $IMG_SIZE
>> +TEST_IMG="$TEST_IMG.overlay0" _make_test_img -b "$TEST_IMG" $IMG_SIZE
>> +TEST_IMG="$TEST_IMG.overlay1" _make_test_img -b "$TEST_IMG" $IMG_SIZE
>> +
>> +# So that we actually have something to mirror and the job does not return
>> +# immediately (which may be bad because then we cannot know whether the
>> +# 'return' or the 'BLOCK_JOB_READY' comes first).
>> +$QEMU_IO -c 'write 0 64' "$TEST_IMG.overlay0" | _filter_qemu_io
>
> 64 bytes? Unusual, but yes, why not. We probably don't test this too
> often. :-)
*cough* well, somehow dropped the k there, but yes...
>> +# We cannot use virtio-blk here because that does not actually set the attached
>> +# BB's AioContext in qtest mode
>
> Why that? I don't see any qtest special casing in the virtio-blk code,
> so is this intentional?
I don't know. But that's at least what I discovered when putting debug
code into bdrv_open_backing_file(); the overlay was still attached to
the main qemu AioContext.
>> +_launch_qemu \
>> + -object iothread,id=iothr \
>> + -blockdev node-name=source,driver=$IMGFMT,file.driver=file,file.filename="$TEST_IMG.overlay0" \
>> + -device virtio-scsi,id=scsi-bus,iothread=iothr \
>> + -device scsi-hd,bus=scsi-bus.0,drive=source
>> +
>> +_send_qemu_cmd $QEMU_HANDLE \
>> + "{ 'execute': 'qmp_capabilities' }" \
>> + 'return'
>> +
>> +_send_qemu_cmd $QEMU_HANDLE \
>> + "{ 'execute': 'drive-mirror',
>> + 'arguments': {
>> + 'job-id': 'mirror',
>> + 'device': 'source',
>> + 'target': '$TEST_IMG.overlay1',
>> + 'mode': 'existing',
>> + 'sync': 'top'
>> + } }" \
>> + 'BLOCK_JOB_READY'
>> +
>> +# The backing BDS should be assigned the overlay's AioContext
>> +_send_qemu_cmd $QEMU_HANDLE \
>> + "{ 'execute': 'block-job-complete',
>> + 'arguments': { 'device': 'mirror' } }" \
>> + 'BLOCK_JOB_COMPLETED'
>> +
>> +_send_qemu_cmd $QEMU_HANDLE \
>> + "{ 'execute': 'quit' }" \
>> + 'return'
>> +
>> +wait=yes _cleanup_qemu
>> +
>> +# success, all done
>> +echo '*** done'
>> +rm -f $seq.full
>> +status=0
>
> The actual test looks good to me.
OK, thanks for reviewing. I'll just send a v2 because I'd like to fix
the 64 (at least change it to 42 so people don't think it's by accident!
*cough*) and doing both that and giving it a different test number at
the same time seems a bit much.
Or I can just follow your model which is to send it and keep it in my
branch at the same time. :-)
Max
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 498 bytes --]
prev parent reply other threads:[~2017-06-30 2:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-28 23:23 [Qemu-devel] [PATCH] iotests: Add test for dataplane mirroring Max Reitz
2017-06-29 10:10 ` Kevin Wolf
2017-06-30 2:44 ` Max Reitz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bc6ec1d8-f94c-904a-ff38-7c0b886d5d7b@redhat.com \
--to=mreitz@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).