Re: [PATCH v2 06/13] migration: Use VMSTATE_INSTANCE_ID_ANY for s390 devices

Am 20.10.23 um 11:07 schrieb Juan Quintela: Just with make check I can see that we can have more than one of this devices, so use ANY. ok 5 /s390x/device/introspect/abstract-interfaces ... Broken pipe ../../../../../mnt/code/qemu/full/tests/qtest/libqtest.c:195: kill_qemu() tried to terminate

Re: s390 intermittent test failure in qemu:block / io-qcow2-copy-before-write

Am 25.07.23 um 18:45 schrieb Peter Maydell: There seems to be an intermittent failure on the s390 host in the qemu:block / io-qcow2-copy-before-write test: https://gitlab.com/qemu-project/qemu/-/jobs/4737819873 The log says the test was expecting to do some reading and writing but got an

Re: [PATCH 1/1] qemu-iotests/stream-under-throttle: do not shutdown QEMU

Am 07.12.22 um 14:14 schrieb Christian Borntraeger: Without a kernel or boot disk a QEMU on s390 will exit (usually with a disabled wait state). This breaks the stream-under-throttle test case. Do not exit qemu if on s390. Signed-off-by: Christian Borntraeger --- tests/qemu-iotests/tests

Re: [PATCH 1/1] qemu-iotests/stream-under-throttle: do not shutdown QEMU

Am 07.12.22 um 14:23 schrieb Thomas Huth: On 07/12/2022 14.14, Christian Borntraeger wrote: Without a kernel or boot disk a QEMU on s390 will exit (usually with a disabled wait state). This breaks the stream-under-throttle test case. Do not exit qemu if on s390. Signed-off-by: Christian

[PATCH 1/1] qemu-iotests/stream-under-throttle: do not shutdown QEMU

Without a kernel or boot disk a QEMU on s390 will exit (usually with a disabled wait state). This breaks the stream-under-throttle test case. Do not exit qemu if on s390. Signed-off-by: Christian Borntraeger --- tests/qemu-iotests/tests/stream-under-throttle | 2 ++ 1 file changed, 2 insertions

Re: [PATCH v2] tests/stream-under-throttle: New test

Am 07.12.22 um 13:56 schrieb Christian Borntraeger: Am 07.12.22 um 11:31 schrieb Christian Borntraeger: Am 14.11.22 um 10:52 schrieb Hanna Reitz: Test streaming a base image into the top image underneath two throttle nodes.  This was reported to make qemu 7.1 hang (https://gitlab.com/qemu

Re: [PATCH v2] tests/stream-under-throttle: New test

Am 07.12.22 um 11:31 schrieb Christian Borntraeger: Am 14.11.22 um 10:52 schrieb Hanna Reitz: Test streaming a base image into the top image underneath two throttle nodes.  This was reported to make qemu 7.1 hang (https://gitlab.com/qemu-project/qemu/-/issues/1215), so this serves

Re: [PATCH v2] tests/stream-under-throttle: New test

Am 14.11.22 um 10:52 schrieb Hanna Reitz: Test streaming a base image into the top image underneath two throttle nodes. This was reported to make qemu 7.1 hang (https://gitlab.com/qemu-project/qemu/-/issues/1215), so this serves as a regression test. Signed-off-by: Hanna Reitz --- Based-on:

Re: qemu iotest 161 and make check

Am 27.10.22 um 07:54 schrieb Christian Borntraeger: [...] diff --git a/tests/qemu-iotests/common.qemu b/tests/qemu-iotests/common.qemu index 0f1fecc68e..01bdb05575 100644 --- a/tests/qemu-iotests/common.qemu +++ b/tests/qemu-iotests/common.qemu @@ -388,7 +388,7 @@ _cleanup_qemu

Re: [PATCH v1 5/9] hw/virtio: introduce virtio_device_should_start

Am 21.11.22 um 23:37 schrieb Michael S. Tsirkin: [...] qemu-system-x86_64: ../hw/virtio/vhost-vsock-common.c:203: vhost_vsock_common_pre_save: Assertion `!vhost_dev_is_started(>vhost_dev)' failed. 2022-11-15 16:38:46.096+: shutting down, reason=crashed Alex were you able to replicate?

Re: [PATCH v1 5/9] hw/virtio: introduce virtio_device_should_start

Am 15.11.22 um 17:40 schrieb Christian Borntraeger: Am 15.11.22 um 17:05 schrieb Alex Bennée: Christian Borntraeger writes: Am 15.11.22 um 15:31 schrieb Alex Bennée: "Michael S. Tsirkin" writes: On Mon, Nov 14, 2022 at 06:15:30PM +0100, Christian Borntraeger wrote: A

Re: [PATCH v1 5/9] hw/virtio: introduce virtio_device_should_start

Am 15.11.22 um 17:05 schrieb Alex Bennée: Christian Borntraeger writes: Am 15.11.22 um 15:31 schrieb Alex Bennée: "Michael S. Tsirkin" writes: On Mon, Nov 14, 2022 at 06:15:30PM +0100, Christian Borntraeger wrote: Am 14.11.22 um 18:10 schrieb Michael S. Tsirkin: On M

Re: [PATCH v1 5/9] hw/virtio: introduce virtio_device_should_start

Am 15.11.22 um 15:31 schrieb Alex Bennée: "Michael S. Tsirkin" writes: On Mon, Nov 14, 2022 at 06:15:30PM +0100, Christian Borntraeger wrote: Am 14.11.22 um 18:10 schrieb Michael S. Tsirkin: On Mon, Nov 14, 2022 at 05:55:09PM +0100, Christian Borntraeger wrote: Am 14.11.2

Re: [PATCH v1 5/9] hw/virtio: introduce virtio_device_should_start

Am 15.11.22 um 12:25 schrieb Michael S. Tsirkin: On Tue, Nov 15, 2022 at 09:18:27AM +0100, Christian Borntraeger wrote: Am 14.11.22 um 18:20 schrieb Michael S. Tsirkin: On Mon, Nov 14, 2022 at 06:15:30PM +0100, Christian Borntraeger wrote: Am 14.11.22 um 18:10 schrieb Michael S. Tsirkin

Re: [PATCH v1 5/9] hw/virtio: introduce virtio_device_should_start

Am 14.11.22 um 18:20 schrieb Michael S. Tsirkin: On Mon, Nov 14, 2022 at 06:15:30PM +0100, Christian Borntraeger wrote: Am 14.11.22 um 18:10 schrieb Michael S. Tsirkin: On Mon, Nov 14, 2022 at 05:55:09PM +0100, Christian Borntraeger wrote: Am 14.11.22 um 17:37 schrieb Michael S. Tsirkin

Re: [PATCH v1 5/9] hw/virtio: introduce virtio_device_should_start

Am 14.11.22 um 18:20 schrieb Michael S. Tsirkin: [...] This does not seem to fix the regression that I have reported. This was applied on top of 9f6bcfd99f which IIUC does, right? Just dobble checked, 9f6bcfd99f was the patch that created the original problem, no?

Re: [PATCH v1 5/9] hw/virtio: introduce virtio_device_should_start

Am 08.11.22 um 10:23 schrieb Alex Bennée: The previous fix to virtio_device_started revealed a problem in its use by both the core and the device code. The core code should be able to handle the device "starting" while the VM isn't running to handle the restoration of migration state. To solve

Re: [PATCH v1 5/9] hw/virtio: introduce virtio_device_should_start

Am 14.11.22 um 17:37 schrieb Michael S. Tsirkin: On Mon, Nov 14, 2022 at 05:18:53PM +0100, Christian Borntraeger wrote: Am 08.11.22 um 10:23 schrieb Alex Bennée: The previous fix to virtio_device_started revealed a problem in its use by both the core and the device code. The core code

Re: [PATCH v1 5/9] hw/virtio: introduce virtio_device_should_start

Am 14.11.22 um 18:10 schrieb Michael S. Tsirkin: On Mon, Nov 14, 2022 at 05:55:09PM +0100, Christian Borntraeger wrote: Am 14.11.22 um 17:37 schrieb Michael S. Tsirkin: On Mon, Nov 14, 2022 at 05:18:53PM +0100, Christian Borntraeger wrote: Am 08.11.22 um 10:23 schrieb Alex Bennée

Re: qemu iotest 161 and make check

Am 31.03.22 um 10:25 schrieb Christian Borntraeger: Am 31.03.22 um 09:44 schrieb Christian Borntraeger: Am 21.02.22 um 11:27 schrieb Christian Borntraeger: Am 10.02.22 um 18:44 schrieb Vladimir Sementsov-Ogievskiy: 10.02.2022 20:13, Thomas Huth wrote: On 10/02/2022 15.51, Christian

Re: qemu iotest 161 and make check

Am 31.03.22 um 09:44 schrieb Christian Borntraeger: Am 21.02.22 um 11:27 schrieb Christian Borntraeger: Am 10.02.22 um 18:44 schrieb Vladimir Sementsov-Ogievskiy: 10.02.2022 20:13, Thomas Huth wrote: On 10/02/2022 15.51, Christian Borntraeger wrote: Am 10.02.22 um 15:47 schrieb

Re: qemu iotest 161 and make check

Am 21.02.22 um 11:27 schrieb Christian Borntraeger: Am 10.02.22 um 18:44 schrieb Vladimir Sementsov-Ogievskiy: 10.02.2022 20:13, Thomas Huth wrote: On 10/02/2022 15.51, Christian Borntraeger wrote: Am 10.02.22 um 15:47 schrieb Vladimir Sementsov-Ogievskiy: 10.02.2022 10:57, Christian

Re: qemu iotest 161 and make check

Am 10.02.22 um 18:44 schrieb Vladimir Sementsov-Ogievskiy: 10.02.2022 20:13, Thomas Huth wrote: On 10/02/2022 15.51, Christian Borntraeger wrote: Am 10.02.22 um 15:47 schrieb Vladimir Sementsov-Ogievskiy: 10.02.2022 10:57, Christian Borntraeger wrote: Hello, I do see spurious failures

Re: qemu iotest 161 and make check

Am 10.02.22 um 15:47 schrieb Vladimir Sementsov-Ogievskiy: 10.02.2022 10:57, Christian Borntraeger wrote: Hello, I do see spurious failures of 161 in our CI, but only when I use make check with parallelism (-j). I have not yet figured out which other testcase could interfere @@ -34,6 +34,8

Re: qemu iotest 161 and make check

Am 10.02.22 um 15:47 schrieb Vladimir Sementsov-Ogievskiy: 10.02.2022 10:57, Christian Borntraeger wrote: Hello, I do see spurious failures of 161 in our CI, but only when I use make check with parallelism (-j). I have not yet figured out which other testcase could interfere @@ -34,6 +34,8

qemu iotest 161 and make check

Hello, I do see spurious failures of 161 in our CI, but only when I use make check with parallelism (-j). I have not yet figured out which other testcase could interfere @@ -34,6 +34,8 @@ *** Commit and then change an option on the backing file Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT

regression on s390: was Re: [PULL 37/40] monitor: Tidy up find_device_state()

Am 15.10.21 um 21:15 schrieb Richard Henderson: On 10/15/21 4:08 AM, Christian Borntraeger wrote: Am 13.10.21 um 11:07 schrieb Paolo Bonzini: From: Markus Armbruster Commit 6287d827d4 "monitor: allow device_del to accept QOM paths" extended find_device_state() to accept

Re: [PULL 37/40] monitor: Tidy up find_device_state()

Am 13.10.21 um 11:07 schrieb Paolo Bonzini: From: Markus Armbruster Commit 6287d827d4 "monitor: allow device_del to accept QOM paths" extended find_device_state() to accept QOM paths in addition to qdev IDs. This added a checked conversion to TYPE_DEVICE at the end, which duplicates the

Re: [PATCH] block: introduce max_hw_iov for use in scsi-generic

Peter, Michael, do we still do stable releases for QEMU or has this stopped? Am 24.09.21 um 07:27 schrieb Paolo Bonzini: Yes, the question is whether it still exists... Paolo El jue., 23 sept. 2021 16:48, Christian Borntraeger escribió: Am 23.09.21 um 15:04 schrieb Paolo Bonzini: > Li

Re: [PATCH] block: introduce max_hw_iov for use in scsi-generic

Am 23.09.21 um 15:04 schrieb Paolo Bonzini: Linux limits the size of iovecs to 1024 (UIO_MAXIOV in the kernel sources, IOV_MAX in POSIX). Because of this, on some host adapters requests with many iovecs are rejected with -EINVAL by the io_submit() or readv()/writev() system calls. In fact,

Recent qemu patch results in aio failures with host DASD disks resulting in guest I/O errors

Am 22.09.21 um 21:51 schrieb Halil Pasic: On Mon, 6 Sep 2021 16:24:20 +0200 Halil Pasic wrote: On Fri, 25 Jun 2021 16:18:12 +0200 Paolo Bonzini wrote: bs->sg is only true for character devices, but block devices can also be used with scsi-block and scsi-generic. Unfortunately BLKSECTGET

qemu io test: spurious failures of 030

Folks, I have CI on s390 on qemu/master for each commit. And from time to time I do get spurious failures of 030. (always 030 and nothing else). I have a hard time reproducing this manually so I cannot debug this at the moment. Has anyone seen this as well? 030

Re: [PATCH 1/1] iotests: fix 051.out expected output after error text touchups

("block: Clarify error messages pertaining to 'node-name'") Signed-off-by: Connor Kuehl Tested-by: Christian Borntraeger Thanks for the quick response. --- tests/qemu-iotests/051.out | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tests/qemu-iotests/051.o

Re: [PATCH v2 0/2] Assorted fixes to tests that were broken by recent scsi changes

that hopefully makes this iotest work on both x86 and s390. > > Best regards, > Maxim Levitsky > > Maxim Levitsky (2): > iotests: add filter_qmp_virtio_scsi function > iotests: rewrite iotest 240 in python Both patches on s390x Tested-by: Christian Borntraeger T

Re: [PATCH 4/4] iotests: rewrite iotest 240 in python

On 19.10.20 18:37, Maxim Levitsky wrote: > The recent changes that brought RCU delayed device deletion, > broke few tests and this test breakage went unnoticed. > > Fix this test by rewriting it in python > (which allows to wait for DEVICE_DELETED events before continuing). While this is now

Re: [PATCH 1/4] vmdk: fix maybe uninitialized warnings

On 30.09.20 18:36, Fam Zheng wrote: > On Wed, 2020-09-30 at 17:58 +0200, Christian Borntraeger wrote: >> Fedora 32 gcc 10 seems to give false positives: >> >> Compiling C object libblock.fa.p/block_vmdk.c.o >> ../block/vmdk.c: In function ‘vmdk_parse_extents’: >

Re: [PATCH 2/4] nbd: silence maybe-uninitialized warnings

On 30.09.20 19:19, Eric Blake wrote: > On 9/30/20 10:58 AM, Christian Borntraeger wrote: >> gcc 10 from Fedora 32 gives me: >> >> Compiling C object libblock.fa.p/nbd_server.c.o >> ../nbd/server.c: In function ‘nbd_co_client_start’: >> ../nbd/server.c:625

Re: [PATCH 4/4] virtiofsd: avoid false positive compiler warning

On 30.09.20 18:27, Dr. David Alan Gilbert wrote: > * Christian Borntraeger (borntrae...@de.ibm.com) wrote: >> make: *** [Makefile:121: config-host.mak] Error 1 >> [cborntra@m83lp52 qemu]$ make -C build/ >> make: Entering directory '/home/cborntra/REPOS/qemu/build' >>

[PATCH 2/4] nbd: silence maybe-uninitialized warnings

namelen; | ^~~ cc1: all warnings being treated as errors As I cannot see how this can happen, let uns silence the warning. Signed-off-by: Christian Borntraeger --- nbd/server.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/nbd/server.c b/nbd/server.c

[PATCH 4/4] virtiofsd: avoid false positive compiler warning

make: *** [Makefile.ninja:1438: tools/virtiofsd/virtiofsd.p/passthrough_ll.c.o] Error 1 make: Leaving directory '/home/cborntra/REPOS/ as far as I can see this can not happen. Let us silence the warning by giving fd a default value. Signed-off-by: Christian Borntraeger --- tools/virtiofsd

[PATCH 3/4] qemu-io-cmds: avoid gcc 10 warning

- 1, __fmt, __va_arg_pack ()); | ^~~ cc1: all warnings being treated as errors Let us check for null. Signed-off-by: Christian Borntraeger --- qemu-io-cmds.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff

[PATCH 1/4] vmdk: fix maybe uninitialized warnings

lt value. Signed-off-by: Christian Borntraeger --- block/vmdk.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/block/vmdk.c b/block/vmdk.c index 8ec62c7ab798..a00dc00eb47a 100644 --- a/block/vmdk.c +++ b/block/vmdk.c @@ -595,7 +595,7 @@ static int vmdk_open_vmfs_sparse

[PATCH 0/4] assorted gcc 10/fedora32 compile warning fixes

I might be wrong and some of these warnings could be correct, so some review from the subject matter experts would be good. Christian Borntraeger (4): vmdk: fix maybe uninitialized warnings nbd: silence maybe-uninitialized warnings qemu-io-cmds: avoid gcc 10 warning virtiofsd: avoid false

Re: [Qemu-block] [PATCH 3/3] i386/kvm: initialize struct at full before ioctl call

On 31.07.19 14:28, Christian Borntraeger wrote: > > > On 31.07.19 14:04, Andrey Shinkevich wrote: >> On 31/07/2019 10:24, Christian Borntraeger wrote: >>> >>> >>> On 30.07.19 21:20, Paolo Bonzini wrote: >>>> On 30/07/19 18:01,

Re: [Qemu-block] [PATCH 3/3] i386/kvm: initialize struct at full before ioctl call

On 31.07.19 14:04, Andrey Shinkevich wrote: > On 31/07/2019 10:24, Christian Borntraeger wrote: >> >> >> On 30.07.19 21:20, Paolo Bonzini wrote: >>> On 30/07/19 18:01, Andrey Shinkevich wrote: >>>> Not the whole structure is initialized before pas

Re: [Qemu-block] [PATCH 3/3] i386/kvm: initialize struct at full before ioctl call

On 30.07.19 21:20, Paolo Bonzini wrote: > On 30/07/19 18:01, Andrey Shinkevich wrote: >> Not the whole structure is initialized before passing it to the KVM. >> Reduce the number of Valgrind reports. >> >> Signed-off-by: Andrey Shinkevich > > Christian, is this the right fix? It's not

Re: [Qemu-block] [Qemu-devel] [PATCH 3/3] i386/kvm: initialize struct at full before ioctl call

On 30.07.19 19:14, Philippe Mathieu-Daudé wrote: > On 7/30/19 7:05 PM, Christian Borntraeger wrote: >> On 30.07.19 18:44, Philippe Mathieu-Daudé wrote: >>> On 7/30/19 6:01 PM, Andrey Shinkevich wrote: >>>> Not the whole structure is initialized before pass

Re: [Qemu-block] [Qemu-devel] [PATCH 3/3] i386/kvm: initialize struct at full before ioctl call

On 30.07.19 18:46, Peter Maydell wrote: > On Tue, 30 Jul 2019 at 17:05, Andrey Shinkevich > wrote: >> >> Not the whole structure is initialized before passing it to the KVM. >> Reduce the number of Valgrind reports. >> >> Signed-off-by: Andrey Shinkevich > > Does it even make sense to try to

Re: [Qemu-block] [Qemu-devel] [PATCH 3/3] i386/kvm: initialize struct at full before ioctl call

PUState *cs) >> return 0; >> } >> >> +memset(_data, 0, sizeof(msr_data)); > > I wonder the overhead of this one... Cant we use designated initializers like in commit bdfc8480c50a53d91aa9a513d23a84de0d5fbc86 Author: Christian Borntraeger A

Re: [Qemu-block] [PATCH] Fixes: a6862418fec4072 iotests change in 051.out

On 24.07.19 10:25, Andrey Shinkevich wrote: > The patch "iotests: Set read-zeroes on in null block driver for Valgrind" > needs the change in 051.out when compared against on the s390 system. > > Reported-by: Christian Borntraeger Tested-by: Christian Borntraeger FWIW

Re: [Qemu-block] [Qemu-devel] [PULL 01/13] iotests: Set read-zeroes on in null block driver for Valgrind

On 24.07.19 09:30, Andrey Shinkevich wrote: > > > On 24/07/2019 10:18, Christian Borntraeger wrote: >> >> On 19.07.19 15:43, Kevin Wolf wrote: >>> From: Andrey Shinkevich >>> >>> The Valgrind tool reports about the uninitialised buffer 'bu

Re: [Qemu-block] [Qemu-devel] [PULL 01/13] iotests: Set read-zeroes on in null block driver for Valgrind

On 19.07.19 15:43, Kevin Wolf wrote: > From: Andrey Shinkevich > > The Valgrind tool reports about the uninitialised buffer 'buf' > instantiated on the stack of the function guess_disk_lchs(). > Pass 'read-zeroes=on' to the null block driver to make it deterministic. > The output of the tests

Re: [Qemu-block] [Qemu-devel] [PATCH 0/6] tests/qemu-iotests: Run basic iotests during "make check"

ease (e.g. by a qemu-io change) consider the series Acked-by: Christian Borntraeger > > Thomas Huth (6): > tests/qemu-iotests/check: Pick a default machine if necessary > tests/qemu-iotests/group: Introduce a new "ci" group for CI pipelines > tests/qemu-iotests:

Re: [Qemu-block] [Qemu-devel] [PATCH v3 8/8] RFC iotests: Disable 236 and 238 on OpenBSD

FWIW 238 also fails on my s390 box: qemu-iotests]$ ./check -qcow2 238 QEMU -- "/home/cborntra/REPOS/qemu/build/tests/qemu-iotests/../../s390x-softmmu/qemu-system-s390x" -nodefaults -machine accel=qtest QEMU_IMG --

Re: [Qemu-block] [qemu-s390x] [Qemu-devel] [PULL 2/2] iotests: simple mirror test with kvm on 1G image

On 05.12.2018 17:09, Vladimir Sementsov-Ogievskiy wrote: > 05.12.2018 18:52, Christian Borntraeger wrote: >> >> >> On 05.12.2018 14:39, Vladimir Sementsov-Ogievskiy wrote: >>> 05.12.2018 15:35, Christian Borntraeger wrote: >>>> >>>> >&g

Re: [Qemu-block] [qemu-s390x] [Qemu-devel] [PULL 2/2] iotests: simple mirror test with kvm on 1G image

On 05.12.2018 17:09, Vladimir Sementsov-Ogievskiy wrote: > 05.12.2018 18:52, Christian Borntraeger wrote: >> >> >> On 05.12.2018 14:39, Vladimir Sementsov-Ogievskiy wrote: >>> 05.12.2018 15:35, Christian Borntraeger wrote: >>>> >>>> >&g

Re: [Qemu-block] [qemu-s390x] [Qemu-devel] [PULL 2/2] iotests: simple mirror test with kvm on 1G image

On 05.12.2018 14:39, Vladimir Sementsov-Ogievskiy wrote: > 05.12.2018 15:35, Christian Borntraeger wrote: >> >> >> On 05.12.2018 13:00, Vladimir Sementsov-Ogievskiy wrote: >>> 05.12.2018 12:01, Christian Borntraeger wrote: >>>> >>>>

Re: [Qemu-block] [qemu-s390x] [Qemu-devel] [PULL 2/2] iotests: simple mirror test with kvm on 1G image

On 05.12.2018 13:00, Vladimir Sementsov-Ogievskiy wrote: > 05.12.2018 12:01, Christian Borntraeger wrote: >> >> >> On 05.12.2018 09:46, Kevin Wolf wrote: >>> Am 05.12.2018 um 09:23 hat Christian Borntraeger geschrieben: >>>>>>> +

Re: [Qemu-block] [qemu-s390x] [Qemu-devel] [PULL 2/2] iotests: simple mirror test with kvm on 1G image

On 05.12.2018 09:46, Kevin Wolf wrote: > Am 05.12.2018 um 09:23 hat Christian Borntraeger geschrieben: >>>>> +# prepare source image >>>>> +qemu_img_create('-f', iotests.imgfmt, '-o', 'preallocation=metadata', >>>>> disk, >>>>&

[Qemu-block] [PATCH 1/1] iotests: make 235 work on s390 (and others)

"-machine pc" will not work all architectures. Lets fall back to the default machine by not specifying it. In addition we also need to specify -no-shutdown on s390 as qemu will exit otherwise. Signed-off-by: Christian Borntraeger --- tests/qemu-iotests/235 | 4 +++- 1 file

Re: [Qemu-block] [qemu-s390x] [Qemu-devel] [PULL 2/2] iotests: simple mirror test with kvm on 1G image

On 04.12.2018 14:49, Christian Borntraeger wrote: > > > On 04.12.2018 14:46, Christian Borntraeger wrote: >> FWIW, this testcase fails with current qemu master on s390: >> >> QEMU -- >> "/home/cborntra/REPOS/qemu/build/tests/qemu-iotests

Re: [Qemu-block] [qemu-s390x] [Qemu-devel] [PULL 2/2] iotests: simple mirror test with kvm on 1G image

On 04.12.2018 14:46, Christian Borntraeger wrote: > FWIW, this testcase fails with current qemu master on s390: > > QEMU -- > "/home/cborntra/REPOS/qemu/build/tests/qemu-iotests/../../s390x-softmmu/qemu-system-s390x" > -nodefaults -machine accel=qtest >

Re: [Qemu-block] [Qemu-devel] [PULL 2/2] iotests: simple mirror test with kvm on 1G image

FWIW, this testcase fails with current qemu master on s390: QEMU -- "/home/cborntra/REPOS/qemu/build/tests/qemu-iotests/../../s390x-softmmu/qemu-system-s390x" -nodefaults -machine accel=qtest QEMU_IMG -- "/home/cborntra/REPOS/qemu/build/tests/qemu-iotests/../../qemu-img" QEMU_IO

Re: [Qemu-block] [Qemu-devel] [RFC] Require Python 3 for building QEMU

On 10/15/2018 08:33 PM, Eduardo Habkost wrote: > On Mon, Oct 15, 2018 at 08:19:18PM +0200, Christian Borntraeger wrote: [...] >>>> >>>> It's easier to port stuff to Python 3 though than making them work with >>>> both. I think Eduardo's RFC is in part

Re: [Qemu-block] [Qemu-devel] [RFC] Require Python 3 for building QEMU

On 10/15/2018 06:33 PM, Markus Armbruster wrote: > Kevin Wolf writes: > >> Am 15.10.2018 um 12:02 hat Peter Maydell geschrieben: >>> On 15 October 2018 at 10:32, Daniel P. Berrangé wrote: On Sat, Oct 13, 2018 at 02:02:27AM -0300, Eduardo Habkost wrote: > Signed-off-by: Eduardo

[Qemu-block] forward of qemu bug regarding random qemu hangs at shutdown

Kevin, for reference, it seems that his bug report somehow got lost. https://bugs.launchpad.net/qemu/+bug/1788582

Re: [Qemu-block] [qemu-s390x] [Qemu-devel] [BUG?] aio_get_linux_aio: Assertion `ctx->linux_aio' failed

On 07/18/2018 08:52 PM, Nishanth Aravamudan wrote: > On 18.07.2018 [11:10:27 -0400], Farhan Ali wrote: >> >> >> On 07/18/2018 09:42 AM, Farhan Ali wrote: >>> >>> >>> On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote: iiuc, this possibly implies AIO was not actually used previously on this

Re: [Qemu-block] [Qemu-devel] [libvirt] [PULL 25/26] block: Remove deprecated -drive option serial

On 07/04/2018 03:34 PM, Kevin Wolf wrote: > Am 04.07.2018 um 15:02 hat Cornelia Huck geschrieben: >> On Tue, 3 Jul 2018 13:32:29 +0200 >> Kevin Wolf wrote: >> >> Has serial/gemoetry been fixed meanwhile and will it make it into the >> next release? > > I cannot find an

Re: [Qemu-block] [libvirt] [Qemu-devel] [PULL 25/26] block: Remove deprecated -drive option serial

On 07/03/2018 01:35 PM, Peter Maydell wrote: > On 3 July 2018 at 12:32, Kevin Wolf wrote: >> Am 03.07.2018 um 13:22 hat Daniel P. Berrangé geschrieben: >>> Just posted latest version here: >>> >>> https://www.redhat.com/archives/libvir-list/2018-July/msg00130.html >>> >>> It will be in the

Re: [Qemu-block] [libvirt] [Qemu-devel] [PULL 25/26] block: Remove deprecated -drive option serial

0100, Daniel P. Berrangé wrote: >>>>> On Fri, Jun 22, 2018 at 04:25:13PM +0200, Kevin Wolf wrote: >>>>>> Am 22.06.2018 um 15:36 hat Christian Borntraeger geschrieben: >> >> [...] >> >>> >>> Thanks! >>> >>> I'll lo

Re: [Qemu-block] [Qemu-devel] [PULL 25/26] block: Remove deprecated -drive option serial

On 06/22/2018 05:01 PM, Kevin Wolf wrote: > Am 22.06.2018 um 16:38 hat Christian Borntraeger geschrieben: >> >> >> On 06/22/2018 04:25 PM, Kevin Wolf wrote: >>> Am 22.06.2018 um 15:36 hat Christian Borntraeger geschrieben: >>>> >>>> &

Re: [Qemu-block] [Qemu-devel] [PULL 25/26] block: Remove deprecated -drive option serial

On 06/22/2018 04:25 PM, Kevin Wolf wrote: > Am 22.06.2018 um 15:36 hat Christian Borntraeger geschrieben: >> >> >> On 06/22/2018 02:55 PM, Kevin Wolf wrote: >>> Am 22.06.2018 um 13:38 hat Christian Borntraeger geschrieben: >>>> >>>> On 0

Re: [Qemu-block] [Qemu-devel] [PULL 25/26] block: Remove deprecated -drive option serial

On 06/22/2018 03:36 PM, Christian Borntraeger wrote: > > > On 06/22/2018 02:55 PM, Kevin Wolf wrote: >> Am 22.06.2018 um 13:38 hat Christian Borntraeger geschrieben: >>> >>> On 06/15/2018 04:21 PM, Kevin Wolf wrote: >>>> The -drive option

Re: [Qemu-block] [Qemu-devel] [PULL 25/26] block: Remove deprecated -drive option serial

On 06/22/2018 02:55 PM, Kevin Wolf wrote: > Am 22.06.2018 um 13:38 hat Christian Borntraeger geschrieben: >> >> On 06/15/2018 04:21 PM, Kevin Wolf wrote: >>> The -drive option serial was deprecated in QEMU 2.10. It's time to >>> remove it. >>> >

[Qemu-block] request a revert for "block: Remove deprecated -drive option serial" (was block: Remove deprecated -drive option serial)

adding more CC. On 06/22/2018 01:38 PM, Christian Borntraeger wrote: > > On 06/15/2018 04:21 PM, Kevin Wolf wrote: >> The -drive option serial was deprecated in QEMU 2.10. It's time to >> remove it. >> >> Tests need to be updated to set the serial number wi

Re: [Qemu-block] [Qemu-devel] [PULL 25/26] block: Remove deprecated -drive option serial

On 06/15/2018 04:21 PM, Kevin Wolf wrote: > The -drive option serial was deprecated in QEMU 2.10. It's time to > remove it. > > Tests need to be updated to set the serial number with -global instead > of using the -drive option. libvirt 4.5 still creates those (at least on s390x)

Re: [Qemu-block] [PATCH v1 1/1] iotests: fix test case 185

On 03/19/2018 05:10 PM, Stefan Hajnoczi wrote: > On Mon, Mar 19, 2018 at 9:35 AM, QingFeng Hao > wrote: >> Test case 185 failed since commit 4486e89c219 --- "vl: introduce >> vm_shutdown()". >> It's because of the newly introduced function vm_shutdown calls >>

Re: [Qemu-block] [Qemu-devel] [PULL 7/7] vl: introduce vm_shutdown()

On 03/12/2018 08:05 PM, John Snow wrote: > > > On 03/09/2018 08:19 AM, Stefan Hajnoczi wrote: >> Commit 00d09fdbbae5f7864ce754913efc84c12fdf9f1a ("vl: pause vcpus before >> stopping iothreads") and commit dce8921b2baaf95974af8176406881872067adfa >> ("iothread: Stop threads before main() quits")

Re: [Qemu-block] [qemu-s390x] [PATCH 1/3] tests/boot-sector: Add magic bytes to s390x boot code header

c in pc-bios/s390-ccw/bootmap.c), so > we've got to add them in our boot code here, too. > > Signed-off-by: Thomas Huth <th...@redhat.com> Reviewed-by: Christian Borntraeger <borntrae...@de.ibm.com> > --- > tests/boot-sector.c | 9 ++--- > 1 file changed, 6 ins

Re: [Qemu-block] [PATCH v1 1/1] iotests: bypass s390x for case 200

Nack. This will be fixed by s390/ipl: only print boot menu error if -boot menu=on was specified On 03/06/2018 08:54 AM, QingFeng Hao wrote: > In s390x, the case 200 failed as: > === Starting QEMU VM === > > +QEMU_PROG: boot menu is not supported for this device type. > {"return": {}} > >

Re: [Qemu-block] [PATCH] iotests: Use virtio-blk in 155

On 02/12/2018 01:47 PM, Max Reitz wrote: > Only a few select machine types support floppy drives and there is > actually nothing preventing us from using virtio here, so let's do it. > > Reported-by: Christian Borntraeger <borntrae...@de.ibm.com> > Signed-off-by: Max Rei

Re: [Qemu-block] [Qemu-devel] [PULL 06/29] iotests: Make BD-{remove, insert}-medium use @id

Adding Max and Alberto, I think the issue is that on s390 you cannot add a floppy On 02/12/2018 12:16 PM, Christian Borntraeger wrote: > > On 01/23/2018 03:01 PM, Kevin Wolf wrote: >> From: Max Reitz <mre...@redhat.com> >> >> In some cases, these commands st

Re: [Qemu-block] [Qemu-devel] [PULL 06/29] iotests: Make BD-{remove, insert}-medium use @id

On 01/23/2018 03:01 PM, Kevin Wolf wrote: > From: Max Reitz > > In some cases, these commands still use the deprecated @device > parameter. Fix that so we can later drop that parameter from their > interface. > > Signed-off-by: Max Reitz > Message-id:

Re: [Qemu-block] [Qemu-devel] [PATCH v4 1/1] virtio-scsi-ccw: use ioeventfd even when KVM is disabled

On 07/04/2017 03:23 PM, QingFeng Hao wrote: > This patch is based on a similar patch from Stefan Hajnoczi - > commit c324fd0a39c ("virtio-pci: use ioeventfd even when KVM is disabled") > > Do not check kvm_eventfds_enabled() when KVM is disabled since it > always returns 0. Since commit

Re: [Qemu-block] [Qemu-devel] [PATCH v2 1/1] virtio-scsi-ccw: use ioeventfd even when KVM is disabled

On 07/04/2017 05:41 AM, QingFeng Hao wrote: > > > 在 2017/7/3 18:20, Christian Borntraeger 写道: >> On 07/03/2017 10:51 AM, QingFeng Hao wrote: >>> This patch is based on a similar patch from Stefan Hajnoczi - >>> commit c324fd0a39c (" virtio-pci: use ioeventfd

Re: [Qemu-block] [Qemu-devel] [PATCH v2 1/1] virtio-scsi-ccw: use ioeventfd even when KVM is disabled

On 07/03/2017 10:51 AM, QingFeng Hao wrote: > This patch is based on a similar patch from Stefan Hajnoczi - > commit c324fd0a39c (" virtio-pci: use ioeventfd even when KVM is disabled) > > Do not check kvm_eventfds_enabled() when KVM is disabled since it > always returns 0. Since commit

Re: [Qemu-block] [PATCH 1/1] virtio-scsi-ccw: use ioeventfd even when KVM is disabled

On 07/03/2017 10:08 AM, QingFeng Hao wrote: > > > 在 2017/7/3 15:41, Christian Borntraeger 写道: >> On 07/03/2017 09:38 AM, QingFeng Hao wrote: >>> Do not check kvm_eventfds_enabled() when KVM is disabled since it >>> always returns 0. Since commit 8c56c1a

Re: [Qemu-block] [PATCH 1/1] virtio-scsi-ccw: use ioeventfd even when KVM is disabled

On 07/03/2017 09:38 AM, QingFeng Hao wrote: > Do not check kvm_eventfds_enabled() when KVM is disabled since it > always returns 0. Since commit 8c56c1a592b5092d91da8d8943c1d6462a6f > ("memory: emulate ioeventfd") it has been possible to use ioeventfds in > qtest or TCG mode. > > This patch

Re: [Qemu-block] [Qemu-devel] [PATCH] option: Tweak invalid size error message and unbreak iotest 049

rm...@redhat.com> Tested-by: Christian Borntraeger <borntrae...@de.ibm.com> > --- > tests/qemu-iotests/049.out | 14 +- > util/qemu-option.c | 2 +- > 2 files changed, 10 insertions(+), 6 deletions(-) > > diff --git a/tests/qemu-iotests/049.out b/tests/q

Re: [Qemu-block] [Qemu-devel] [PATCH 00/18] dataplane: remove RFifoLock (including almost all previously sent patches)

On 10/13/2016 07:34 PM, Paolo Bonzini wrote: > This patch reorganizes aio_poll callers to establish new rules for > dataplane locking. The idea is that I/O operations on a dataplane > BDS (i.e. one where the AioContext is not the main one) do not call > aio_poll anymore. Instead, they wait for

Re: [Qemu-block] [Qemu-devel] [PATCH] linux-aio: Handle io_submit() failure gracefully

On 08/09/2016 01:20 PM, Kevin Wolf wrote: > It is generally not expected that io_submit() fails other than with > -EAGAIN, but corner cases like SELinux refusing I/O when permissions are > revoked are still possible. In this case, we shouldn't abort, but just > return an I/O error for the request.

Re: [Qemu-block] [PATCH] virtio-blk: assert on starting/stopping

On 04/03/2016 12:37 PM, Michael S. Tsirkin wrote: > Reentrancy cannot happen while the BQL is being held, > so we should never enter this condition. > > Cc: Christian Borntraeger <borntrae...@de.ibm.com> > Cc: Cornelia Huck <cornelia.h...@de.ibm.com> > Cc: Paol

Re: [Qemu-block] [Qemu-devel] [PATCH] block: Move away from anglo-centricity

evin, I think it will be fine to > translate the comments into German, as that is supposedly a language we > both share. Acked-by: Christian Borntraeger <borntrae...@de.ibm.com> > > I'm certain that this will not hamper development itself by much. First > of all, many other developers in the block

Re: [Qemu-block] [PATCH 4/4] virtio-blk: Clean up start/stop with mutex and BH

On 03/23/2016 10:08 AM, Paolo Bonzini wrote: > > > On 23/03/2016 09:10, Cornelia Huck wrote: >>> -/* Kick right away to begin processing requests already in vring */ >>> -event_notifier_set(virtio_queue_get_host_notifier(s->vq)); >>> +vblk->dataplane_started = true; >>> >>> -/*

Re: [Qemu-block] [PATCH v2] Replaced get_tick_per_sec() by NANOSECONDS_PER_SECOND

On 03/20/2016 07:31 PM, rutu.shah...@gmail.com wrote: > From: Rutuja Shah Can you add the patch description (with examples of why this is the right thing to do) here and not in the cover letter? > > Signed-off-by: Rutuja Shah > > --- >

Re: [Qemu-block] [Qemu-devel] [PATCH 0/4] Tweaks around virtio-blk start/stop

On 03/17/2016 04:02 PM, Paolo Bonzini wrote: > > > On 17/03/2016 13:39, Christian Borntraeger wrote: >> As an interesting side note, I updated my system from F20 to F23 some days >> ago >> (after the initial report). While To Bo is still on a F20 system. I was n

Re: [Qemu-block] [Qemu-devel] [PATCH 0/4] Tweaks around virtio-blk start/stop

On 03/17/2016 04:15 PM, Christian Borntraeger wrote: > On 03/17/2016 04:02 PM, Paolo Bonzini wrote: >> >> >> On 17/03/2016 13:39, Christian Borntraeger wrote: >>> As an interesting side note, I updated my system from F20 to F23 some days >>> ago >

Re: [Qemu-block] [Qemu-devel] [PATCH 0/4] Tweaks around virtio-blk start/stop

On 03/17/2016 01:22 PM, tu bo wrote: > > On 03/16/2016 09:38 PM, Christian Borntraeger wrote: >> On 03/16/2016 01:55 PM, Paolo Bonzini wrote: >>> >>> >>> On 16/03/2016 12:24, Christian Borntraeger wrote: >>>> On 03/16/2016 12:09 PM, Paolo

Re: [Qemu-block] [Qemu-devel] [PATCH 0/4] Tweaks around virtio-blk start/stop

On 03/17/2016 04:02 PM, Paolo Bonzini wrote: > > > On 17/03/2016 13:39, Christian Borntraeger wrote: >> As an interesting side note, I updated my system from F20 to F23 some days >> ago >> (after the initial report). While To Bo is still on a F20 system. I was n

Re: [Qemu-block] [PATCH 0/4] Tweaks around virtio-blk start/stop

On 03/16/2016 12:09 PM, Paolo Bonzini wrote: > > > On 16/03/2016 11:49, Christian Borntraeger wrote: >> Seems to lockup. > > That's an improvement actually. :) > >> Thread 3 (Thread 0x3ff888dc910 (LWP 88958)): >> #0 0x03ff8ca90cd4 in __lll_lock_wai

  1   2   >