This series extends qemu-iotests 068 to also run with iothread enabled.  Doing
so was harder than expected because:

1. ioeventfd is disabled without -M accel=kvm even though it should work
2. loadvm still has an iothread bug

Instead of adding a ./check -iothread option I decided to always run the test.
Kevin recently recommended this approach; the advantage is that iothread *will*
always be tested iothread mode whereas people won't run ./check -iothread.

Stefan Hajnoczi (5):
  virtio-pci: use ioeventfd even when KVM is disabled
  migration: hold AioContext lock for loadvm qemu_fclose()
  qemu-iotests: 068: extract _qemu() function
  qemu-iotests: 068: use -drive/-device instead of -hda
  qemu-iotests: 068: test iothread mode

 hw/virtio/virtio-pci.c     |  2 +-
 migration/savevm.c         |  2 +-
 tests/qemu-iotests/068     | 37 +++++++++++++++++++++++++------------
 tests/qemu-iotests/068.out | 11 ++++++++++-
 4 files changed, 37 insertions(+), 15 deletions(-)

-- 
2.9.4

On Thu, Jun 15, 2017 at 5:38 PM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> This series extends qemu-iotests 068 to also run with iothread enabled.

I forgot to mention: this series is based on Kevin's 'block' branch:

  git://repo.or.cz/qemu/kevin.git block

This is necessary in order to get the "[PATCH v3 0/4] block: fix
'savevm' hang with -object iothread" patches that fix savevm.

Stefan

On 15.06.2017 19:38, Stefan Hajnoczi wrote:
> This series extends qemu-iotests 068 to also run with iothread enabled.  Doing
> so was harder than expected because:
> 
> 1. ioeventfd is disabled without -M accel=kvm even though it should work
> 2. loadvm still has an iothread bug
> 
> Instead of adding a ./check -iothread option I decided to always run the test.
> Kevin recently recommended this approach; the advantage is that iothread *will*
> always be tested iothread mode whereas people won't run ./check -iothread.

Why not just add -iothread option in check-block.sh? We can do an
additional run with -iothread, as it is done for different block
formats.

Because all the test cases already exist, we can just reuse them.
> Stefan Hajnoczi (5):
>    virtio-pci: use ioeventfd even when KVM is disabled
>    migration: hold AioContext lock for loadvm qemu_fclose()
>    qemu-iotests: 068: extract _qemu() function
>    qemu-iotests: 068: use -drive/-device instead of -hda
>    qemu-iotests: 068: test iothread mode
> 
>   hw/virtio/virtio-pci.c     |  2 +-
>   migration/savevm.c         |  2 +-
>   tests/qemu-iotests/068     | 37 +++++++++++++++++++++++++------------
>   tests/qemu-iotests/068.out | 11 ++++++++++-
>   4 files changed, 37 insertions(+), 15 deletions(-)
> 

On Mon, Jun 19, 2017 at 03:26:56PM +0300, Pavel Butsykin wrote:
> On 15.06.2017 19:38, Stefan Hajnoczi wrote:
> > This series extends qemu-iotests 068 to also run with iothread enabled.  Doing
> > so was harder than expected because:
> > 
> > 1. ioeventfd is disabled without -M accel=kvm even though it should work
> > 2. loadvm still has an iothread bug
> > 
> > Instead of adding a ./check -iothread option I decided to always run the test.
> > Kevin recently recommended this approach; the advantage is that iothread *will*
> > always be tested iothread mode whereas people won't run ./check -iothread.
> 
> Why not just add -iothread option in check-block.sh? We can do an
> additional run with -iothread, as it is done for different block
> formats.
> 
> Because all the test cases already exist, we can just reuse them.

From the email:

  "the advantage is that iothread *will* always be tested iothread mode
  whereas people won't run ./check -iothread"

Both approaches have pros and cons.

If we decide to use ./check -iothread then it's necessary to figure out
which tests -iothread even applies to.  Tests that use qemu-img/qemu-io
do not use iothread.  Only tests that launch QEMU can take advantage of
iothread today.

Stefan

On 05.07.2017 15:55, Stefan Hajnoczi wrote:
> On Mon, Jun 19, 2017 at 03:26:56PM +0300, Pavel Butsykin wrote:
>> On 15.06.2017 19:38, Stefan Hajnoczi wrote:
>>> This series extends qemu-iotests 068 to also run with iothread enabled.  Doing
>>> so was harder than expected because:
>>>
>>> 1. ioeventfd is disabled without -M accel=kvm even though it should work
>>> 2. loadvm still has an iothread bug
>>>
>>> Instead of adding a ./check -iothread option I decided to always run the test.
>>> Kevin recently recommended this approach; the advantage is that iothread *will*
>>> always be tested iothread mode whereas people won't run ./check -iothread.
>>
>> Why not just add -iothread option in check-block.sh? We can do an
>> additional run with -iothread, as it is done for different block
>> formats.
>>
>> Because all the test cases already exist, we can just reuse them.
> 
>  From the email:
> 
>    "the advantage is that iothread *will* always be tested iothread mode
>    whereas people won't run ./check -iothread"
> 
> Both approaches have pros and cons.

Yeah, it'd just be nice to add iothread support for all iotests.

> If we decide to use ./check -iothread then it's necessary to figure out
> which tests -iothread even applies to.  Tests that use qemu-img/qemu-io
> do not use iothread.  Only tests that launch QEMU can take advantage of
> iothread today.

Well, for tests which don't support the -iothread option we can define
something like this:

_unsupported_iothread

or

_unsupported_opts "iothread"

But overall it looks like a separate patch series, which can be done in
the future.

> Stefan
> 

Am 15.06.2017 um 18:38 hat Stefan Hajnoczi geschrieben:
> This series extends qemu-iotests 068 to also run with iothread enabled.  Doing
> so was harder than expected because:
> 
> 1. ioeventfd is disabled without -M accel=kvm even though it should work
> 2. loadvm still has an iothread bug
> 
> Instead of adding a ./check -iothread option I decided to always run the test.
> Kevin recently recommended this approach; the advantage is that iothread *will*
> always be tested iothread mode whereas people won't run ./check -iothread.

Thanks, fixed the intermediate state after patch 3 (without changing the
final state after applying all patches) and applied to the block branch.

Kevin