From: Kevin Wolf <kwolf@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 0/2] Two small fixes to the streaming test case.
Date: Wed, 06 Jun 2012 10:02:53 +0200 [thread overview]
Message-ID: <4FCF0EAD.2010405@redhat.com> (raw)
In-Reply-To: <1338937810-24681-1-git-send-email-pbonzini@redhat.com>
Am 06.06.2012 01:10, schrieb Paolo Bonzini:
> Hi Kevin, please take a look at the attached simple patches.
>
> Paolo
>
> Paolo Bonzini (2):
> qemu-iotests: fill streaming test image with data
> qemu-iotests: start vms in qtest mode
>
> tests/qemu-iotests/030 | 15 +++++++++++++--
> tests/qemu-iotests/iotests.py | 4 +++-
> 2 files changed, 16 insertions(+), 3 deletions(-)
A real patch series is preferable, having the patches as part of your
signature makes quoting them a bit harder with Thunderbird...
> From 644fda4d6da1a5babfc8884f255d87ebaf847616 Mon Sep 17 00:00:00 2001
> From: Paolo Bonzini <pbonzini@redhat.com>
> Date: Wed, 23 May 2012 13:07:56 +0200
> Subject: [PATCH 1/2] qemu-iotests: fill streaming test image with data
>
> This avoids that the job completes too fast when the file system
> reports the hole to QEMU (via FIEMAP or SEEK_HOLE).
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Does this really fix the cause or just a symptom? The commit message
sounds like a race and now we happen to win it again. But maybe it's
just a bad wording that gives the impression.
> ---
> tests/qemu-iotests/030 | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
> index eb7bf99..4ab7d62 100755
> --- a/tests/qemu-iotests/030
> +++ b/tests/qemu-iotests/030
> @@ -21,6 +21,7 @@
> import os
> import iotests
> from iotests import qemu_img, qemu_io
> +import struct
>
> backing_img = os.path.join(iotests.test_dir, 'backing.img')
> mid_img = os.path.join(iotests.test_dir, 'mid.img')
> @@ -48,11 +49,21 @@ class ImageStreamingTestCase(iotests.QMPTestCase):
>
> self.assert_no_active_streams()
>
> + def create_image(self, name, size):
> + file = open(name, 'w')
> + i = 0
> + while i < size:
> + sector = struct.pack('>l504xl', i / 512, i / 512)
> + file.write(sector)
> + i = i + 512
> + file.close()
> +
> +
> class TestSingleDrive(ImageStreamingTestCase):
> image_len = 1 * 1024 * 1024 # MB
>
> def setUp(self):
> - qemu_img('create', backing_img, str(TestSingleDrive.image_len))
> + self.create_image(backing_img, TestSingleDrive.image_len)
How about just adding a qemu_io call instead? Looks a bit nicer to me
than reimplementing it, and would also work if we decided to use a
different backing file format later.
> qemu_img('create', '-f', iotests.imgfmt, '-o', 'backing_file=%s' % backing_img, mid_img)
> qemu_img('create', '-f', iotests.imgfmt, '-o', 'backing_file=%s' % mid_img, test_img)
> self.vm = iotests.VM().add_drive(test_img)
> --
> 1.7.10.1
> From 3ba5810860b2eaba1f01c257aa13e28c6f9e2b3f Mon Sep 17 00:00:00 2001
> From: Paolo Bonzini <pbonzini@redhat.com>
> Date: Wed, 23 May 2012 12:52:07 +0200
> Subject: [PATCH 2/2] qemu-iotests: start vms in qtest mode
>
> This way, they will not execute any code at all. However, right now
> one test is "relying" on being slowed down by TCG executing random
> crap, so change the timeouts there.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
BIOS code is "random crap"? :-)
But I like the idea of using the qtest mode here.
> ---
> tests/qemu-iotests/030 | 2 +-
> tests/qemu-iotests/iotests.py | 4 +++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
> index 4ab7d62..cc671dd 100755
> --- a/tests/qemu-iotests/030
> +++ b/tests/qemu-iotests/030
> @@ -147,7 +147,7 @@ class TestStreamStop(ImageStreamingTestCase):
> result = self.vm.qmp('block-stream', device='drive0')
> self.assert_qmp(result, 'return', {})
>
> - time.sleep(1)
> + time.sleep(0.1)
> events = self.vm.get_qmp_events(wait=False)
> self.assertEqual(events, [], 'unexpected QMP event: %s' % events)
Why is waiting for too _long_ a problem? I would understand if we waited
too short so that the QMP event hasn't arrived yet. But shouldn't you
still get all QMP events if you wait one more second before you fetch them?
> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
> index e27b40e..e05b1d6 100644
> --- a/tests/qemu-iotests/iotests.py
> +++ b/tests/qemu-iotests/iotests.py
> @@ -54,7 +54,9 @@ class VM(object):
> self._qemu_log_path = os.path.join(test_dir, 'qemu-log.%d' % os.getpid())
> self._args = qemu_args + ['-chardev',
> 'socket,id=mon,path=' + self._monitor_path,
> - '-mon', 'chardev=mon,mode=control', '-nographic']
> + '-mon', 'chardev=mon,mode=control',
> + '-qtest', 'stdio', '-machine', 'accel=qtest',
> + '-display', 'none', '-vga', 'none']
> self._num_drives = 0
>
> def add_drive(self, path, opts=''):
> --
> 1.7.10.1
Kevin
next prev parent reply other threads:[~2012-06-06 8:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-05 23:10 [Qemu-devel] [PATCH 0/2] Two small fixes to the streaming test case Paolo Bonzini
2012-06-06 8:02 ` Kevin Wolf [this message]
2012-06-06 12:15 ` Paolo Bonzini
2012-06-06 12:41 ` Kevin Wolf
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=4FCF0EAD.2010405@redhat.com \
--to=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--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).