[Qemu-devel] [PULL v2 0/7] Block patches

[Qemu-devel] [PULL v2 0/7] Block patches

[Kevin Wolf]

The following changes since commit d05ef160453e98546a4197496dc8a3cb2defac53:

  Allow clock_gettime() monotonic clock to be utilized on more OS's (2013-04-04 20:22:45 -0500)

are available in the git repository at:

  git://repo.or.cz/qemu/kevin.git for-anthony

for you to fetch changes up to c2b6ff51e4a3ad1f7ec5dbc94970e9778b31d718:

  qcow2: Fix L1 write error handling in qcow2_update_snapshot_refcount (2013-04-05 18:58:05 +0200)

----------------------------------------------------------------
Kevin Wolf (3):
      usb-storage: Forward serial number to scsi-disk
      qcow2: Return real error in qcow2_update_snapshot_refcount
      qcow2: Fix L1 write error handling in qcow2_update_snapshot_refcount

Stefan Hajnoczi (4):
      block: fix I/O throttling accounting blind spot
      block: keep I/O throttling slice time constant
      block: drop duplicated slice extension code
      block: clean up I/O throttling wait_time code

 block.c                   | 49 +++++++++++++++++++++--------------------------
 block/qcow2-refcount.c    | 25 ++++++++++++------------
 blockdev.c                |  1 -
 hw/pci/pci-hotplug.c      |  2 +-
 hw/scsi-bus.c             |  8 ++++++--
 hw/scsi.h                 |  3 ++-
 hw/usb/dev-storage.c      |  2 +-
 include/block/block_int.h |  3 +--
 8 files changed, 46 insertions(+), 47 deletions(-)

[Qemu-devel] [PULL v2 0/7] Block patches

[Stefan Hajnoczi]

The following changes since commit c4a7bf54e588ff2de9fba0898b686156251b2063:

  Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into staging (2015-11-07 19:55:15 +0000)

are available in the git repository at:

  git://github.com/stefanha/qemu.git tags/block-pull-request

for you to fetch changes up to 84aa0140dd4f04f5d993f0db14c40da8d3de2706:

  blockdev: acquire AioContext in hmp_commit() (2015-11-09 10:07:10 +0000)

----------------------------------------------------------------

----------------------------------------------------------------

Denis V. Lunev (1):
  monitor: add missed aio_context_acquire into vm_completion call

Fam Zheng (3):
  aio: Introduce aio_external_disabled
  aio: Introduce aio_context_setup
  aio: Introduce aio-epoll.c

Michael S. Tsirkin (2):
  dataplane: simplify indirect descriptor read
  dataplane: support non-contigious s/g

Stefan Hajnoczi (1):
  blockdev: acquire AioContext in hmp_commit()

 aio-posix.c                 | 188 +++++++++++++++++++++++++++++++++++++++++++-
 aio-win32.c                 |   4 +
 async.c                     |  13 ++-
 blockdev.c                  |  12 ++-
 hw/virtio/dataplane/vring.c |  96 ++++++++++++++--------
 include/block/aio.h         |  24 ++++++
 monitor.c                   |  11 ++-
 7 files changed, 309 insertions(+), 39 deletions(-)

-- 
2.5.0

Re: [Qemu-devel] [PULL v2 0/7] Block patches

[Peter Maydell]

On 9 November 2015 at 10:08, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> The following changes since commit c4a7bf54e588ff2de9fba0898b686156251b2063:
>
>   Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into staging (2015-11-07 19:55:15 +0000)
>
> are available in the git repository at:
>
>   git://github.com/stefanha/qemu.git tags/block-pull-request
>
> for you to fetch changes up to 84aa0140dd4f04f5d993f0db14c40da8d3de2706:
>
>   blockdev: acquire AioContext in hmp_commit() (2015-11-09 10:07:10 +0000)
>
> ----------------------------------------------------------------
>
> ----------------------------------------------------------------

I got that intermittent ivshmem test failure again :-(

ERROR:/home/petmay01/qemu/tests/ivshmem-test.c:345:test_ivshmem_server:
assertion failed (ret != 0): (0 != 0)

I'll retry the tests...

thanks
-- PMM

Re: [Qemu-devel] [PULL v2 0/7] Block patches

[Peter Maydell]

On 9 November 2015 at 12:51, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 9 November 2015 at 10:08, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>> The following changes since commit c4a7bf54e588ff2de9fba0898b686156251b2063:
>>
>>   Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into staging (2015-11-07 19:55:15 +0000)
>>
>> are available in the git repository at:
>>
>>   git://github.com/stefanha/qemu.git tags/block-pull-request
>>
>> for you to fetch changes up to 84aa0140dd4f04f5d993f0db14c40da8d3de2706:
>>
>>   blockdev: acquire AioContext in hmp_commit() (2015-11-09 10:07:10 +0000)
>>
>> ----------------------------------------------------------------
>>
>> ----------------------------------------------------------------
>
> I got that intermittent ivshmem test failure again :-(
>
> ERROR:/home/petmay01/qemu/tests/ivshmem-test.c:345:test_ivshmem_server:
> assertion failed (ret != 0): (0 != 0)
>
> I'll retry the tests...

Yep, worked fine second time, so applied.

Marc-André, can you look into why the ivshmem tests might be intermittently
failing like this, please?

thanks
-- PMM

Re: [Qemu-devel] [PULL v2 0/7] Block patches

[Marc-André Lureau]

Hi

----- Original Message -----
> On 9 November 2015 at 12:51, Peter Maydell <peter.maydell@linaro.org> wrote:
> > On 9 November 2015 at 10:08, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> >> The following changes since commit
> >> c4a7bf54e588ff2de9fba0898b686156251b2063:
> >>
> >>   Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into
> >>   staging (2015-11-07 19:55:15 +0000)
> >>
> >> are available in the git repository at:
> >>
> >>   git://github.com/stefanha/qemu.git tags/block-pull-request
> >>
> >> for you to fetch changes up to 84aa0140dd4f04f5d993f0db14c40da8d3de2706:
> >>
> >>   blockdev: acquire AioContext in hmp_commit() (2015-11-09 10:07:10 +0000)
> >>
> >> ----------------------------------------------------------------
> >>
> >> ----------------------------------------------------------------
> >
> > I got that intermittent ivshmem test failure again :-(
> >
> > ERROR:/home/petmay01/qemu/tests/ivshmem-test.c:345:test_ivshmem_server:
> > assertion failed (ret != 0): (0 != 0)
> >
> > I'll retry the tests...
> 
> Yep, worked fine second time, so applied.
> 
> Marc-André, can you look into why the ivshmem tests might be intermittently
> failing like this, please?

Is this with an slow or emulated host? It could be that the 5s timeout is not enough?

Alternatively, I think I could come up with a framework to put some kind of breakpoints in qemu, and wait until they happen. This would get rid of the timer.

Re: [Qemu-devel] [PULL v2 0/7] Block patches

[Peter Maydell]

On 9 November 2015 at 15:09, Marc-André Lureau <mlureau@redhat.com> wrote:
>> On 9 November 2015 at 12:51, Peter Maydell <peter.maydell@linaro.org> wrote:
>> Marc-André, can you look into why the ivshmem tests might be intermittently
>> failing like this, please?
>
> Is this with an slow or emulated host? It could be that the 5s timeout
> is not enough?

This is with the 32-bit build on a 64-bit ARM server box. So it's
not the fastest machine in the world, but it's not bad either.
It will be using TCG, obviously.

A test which takes 5 seconds to run isn't ideal from a "keep
the make-check time down" perspective either.

thanks
-- PMM

Re: [Qemu-devel] [PULL v2 0/7] Block patches

[Marc-André Lureau]

Hi

----- Original Message -----
> On 9 November 2015 at 15:09, Marc-André Lureau <mlureau@redhat.com> wrote:
> >> On 9 November 2015 at 12:51, Peter Maydell <peter.maydell@linaro.org>
> >> wrote:
> >> Marc-André, can you look into why the ivshmem tests might be
> >> intermittently
> >> failing like this, please?
> >
> > Is this with an slow or emulated host? It could be that the 5s timeout
> > is not enough?
> 
> This is with the 32-bit build on a 64-bit ARM server box. So it's
> not the fastest machine in the world, but it's not bad either.
> It will be using TCG, obviously.
> 
> A test which takes 5 seconds to run isn't ideal from a "keep
> the make-check time down" perspective either.

I can imagine a test starting a server thread and 2 qemu instances would take more than 5s on such configuration then.

Could you try timing the test a few times to confirm this?

If it's too long, I suggest we move it to g_test_slow(), and perhaps get rid of the timer. 

thanks

Re: [Qemu-devel] [PULL v2 0/7] Block patches

[Peter Maydell]

On 9 November 2015 at 17:50, Marc-André Lureau <mlureau@redhat.com> wrote:
> Hi
>
> ----- Original Message -----
>> On 9 November 2015 at 15:09, Marc-André Lureau <mlureau@redhat.com> wrote:
>> >> On 9 November 2015 at 12:51, Peter Maydell <peter.maydell@linaro.org>
>> >> wrote:
>> >> Marc-André, can you look into why the ivshmem tests might be
>> >> intermittently
>> >> failing like this, please?
>> >
>> > Is this with an slow or emulated host? It could be that the 5s timeout
>> > is not enough?
>>
>> This is with the 32-bit build on a 64-bit ARM server box. So it's
>> not the fastest machine in the world, but it's not bad either.
>> It will be using TCG, obviously.
>>
>> A test which takes 5 seconds to run isn't ideal from a "keep
>> the make-check time down" perspective either.
>
> I can imagine a test starting a server thread and 2 qemu instances would take more than 5s on such configuration then.
>
> Could you try timing the test a few times to confirm this?

petmay01@moonshot-dsg-11:~/qemu/build/all-a64$ time
QTEST_QEMU_BINARY=i386-softmmu/qemu-system-i386
QTEST_QEMU_IMG=qemu-img MALLOC_PERTURB_=${MALLOC_PERTURB_:-$((RANDOM %
255 + 1))} gtester -k --verbose -m=quick tests/ivshmem-test
TEST: tests/ivshmem-test... (pid=10893)
  /i386/ivshmem/single:                                                OK
  /i386/ivshmem/pair:                                                  OK
  /i386/ivshmem/server:                                                OK
  /i386/ivshmem/hotplug:                                               OK
  /i386/ivshmem/memdev:                                                OK
PASS: tests/ivshmem-test

real    0m11.945s
user    0m11.020s
sys     0m0.310s

(almost all of the runtime seems to be in the "pair" subtest).

thanks
-- PMM

Re: [Qemu-devel] [PULL v2 0/7] Block patches

[Peter Maydell]

On 10 November 2015 at 18:41, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 9 November 2015 at 17:50, Marc-André Lureau <mlureau@redhat.com> wrote:
>> I can imagine a test starting a server thread and 2 qemu instances
>> would take more than 5s on such configuration then.
>>
>> Could you try timing the test a few times to confirm this?
>
> petmay01@moonshot-dsg-11:~/qemu/build/all-a64$ time
> QTEST_QEMU_BINARY=i386-softmmu/qemu-system-i386
> QTEST_QEMU_IMG=qemu-img MALLOC_PERTURB_=${MALLOC_PERTURB_:-$((RANDOM %
> 255 + 1))} gtester -k --verbose -m=quick tests/ivshmem-test
> TEST: tests/ivshmem-test... (pid=10893)
>   /i386/ivshmem/single:                                                OK
>   /i386/ivshmem/pair:                                                  OK
>   /i386/ivshmem/server:                                                OK
>   /i386/ivshmem/hotplug:                                               OK
>   /i386/ivshmem/memdev:                                                OK
> PASS: tests/ivshmem-test
>
> real    0m11.945s
> user    0m11.020s
> sys     0m0.310s
>
> (almost all of the runtime seems to be in the "pair" subtest).

This is now failing on practically every pull request I test.
Please post a patch to fix this test or disable it...

thanks
-- PMM

Re: [Qemu-devel] [PULL v2 0/7] Block patches

[Marc-André Lureau]

[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]

Hi Peter

On Wed, Nov 11, 2015 at 9:33 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 10 November 2015 at 18:41, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 9 November 2015 at 17:50, Marc-André Lureau <mlureau@redhat.com> wrote:
>>> I can imagine a test starting a server thread and 2 qemu instances
>>> would take more than 5s on such configuration then.
>>>
>>> Could you try timing the test a few times to confirm this?
>>
>> petmay01@moonshot-dsg-11:~/qemu/build/all-a64$ time
>> QTEST_QEMU_BINARY=i386-softmmu/qemu-system-i386
>> QTEST_QEMU_IMG=qemu-img MALLOC_PERTURB_=${MALLOC_PERTURB_:-$((RANDOM %
>> 255 + 1))} gtester -k --verbose -m=quick tests/ivshmem-test
>> TEST: tests/ivshmem-test... (pid=10893)
>>   /i386/ivshmem/single:                                                OK
>>   /i386/ivshmem/pair:                                                  OK
>>   /i386/ivshmem/server:                                                OK
>>   /i386/ivshmem/hotplug:                                               OK
>>   /i386/ivshmem/memdev:                                                OK
>> PASS: tests/ivshmem-test
>>
>> real    0m11.945s
>> user    0m11.020s
>> sys     0m0.310s
>>
>> (almost all of the runtime seems to be in the "pair" subtest).
>
> This is now failing on practically every pull request I test.
> Please post a patch to fix this test or disable it...

This is the simplest patch I suggest for now.

-- 
Marc-André Lureau

[-- Attachment #2: 0001-tests-classify-some-ivshmem-tests-as-slow.patch --]
[-- Type: text/x-patch, Size: 1313 bytes --]

From 44f229675d4c9ea896fa83e8cbe5add4c5846541 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau@redhat.com>
Date: Wed, 11 Nov 2015 21:47:05 +0100
Subject: [PATCH] tests: classify some ivshmem tests as slow
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Some tests may take long to run, move them under g_test_slow()
condition.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 tests/ivshmem-test.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tests/ivshmem-test.c b/tests/ivshmem-test.c
index c8f0cf0..f1793ba 100644
--- a/tests/ivshmem-test.c
+++ b/tests/ivshmem-test.c
@@ -478,10 +478,12 @@ int main(int argc, char **argv)
     tmpserver = g_strconcat(tmpdir, "/server", NULL);
 
     qtest_add_func("/ivshmem/single", test_ivshmem_single);
-    qtest_add_func("/ivshmem/pair", test_ivshmem_pair);
-    qtest_add_func("/ivshmem/server", test_ivshmem_server);
     qtest_add_func("/ivshmem/hotplug", test_ivshmem_hotplug);
     qtest_add_func("/ivshmem/memdev", test_ivshmem_memdev);
+    if (g_test_slow()) {
+        qtest_add_func("/ivshmem/pair", test_ivshmem_pair);
+        qtest_add_func("/ivshmem/server", test_ivshmem_server);
+    }
 
     ret = g_test_run();
 
-- 
2.5.0

Re: [Qemu-devel] [PULL v2 0/7] Block patches

[Peter Maydell]

On 11 November 2015 at 20:59, Marc-André Lureau
<marcandre.lureau@gmail.com> wrote:
> Hi Peter
>
> On Wed, Nov 11, 2015 at 9:33 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 10 November 2015 at 18:41, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> On 9 November 2015 at 17:50, Marc-André Lureau <mlureau@redhat.com> wrote:
>>>> I can imagine a test starting a server thread and 2 qemu instances
>>>> would take more than 5s on such configuration then.
>>>>
>>>> Could you try timing the test a few times to confirm this?
>>>
>>> petmay01@moonshot-dsg-11:~/qemu/build/all-a64$ time
>>> QTEST_QEMU_BINARY=i386-softmmu/qemu-system-i386
>>> QTEST_QEMU_IMG=qemu-img MALLOC_PERTURB_=${MALLOC_PERTURB_:-$((RANDOM %
>>> 255 + 1))} gtester -k --verbose -m=quick tests/ivshmem-test
>>> TEST: tests/ivshmem-test... (pid=10893)
>>>   /i386/ivshmem/single:                                                OK
>>>   /i386/ivshmem/pair:                                                  OK
>>>   /i386/ivshmem/server:                                                OK
>>>   /i386/ivshmem/hotplug:                                               OK
>>>   /i386/ivshmem/memdev:                                                OK
>>> PASS: tests/ivshmem-test
>>>
>>> real    0m11.945s
>>> user    0m11.020s
>>> sys     0m0.310s
>>>
>>> (almost all of the runtime seems to be in the "pair" subtest).
>>
>> This is now failing on practically every pull request I test.
>> Please post a patch to fix this test or disable it...
>
> This is the simplest patch I suggest for now.

That will still mean that trying the slow tests gives random
failures, so this still needs attention (ie raising the timeouts
to something that won't actually be hit), but I guess it will
solve my immediate problem. Can you send it to the list as
a proper patch, please?

thanks
-- PMM