OSError can't be used like a tuple on Python 3, so change the
code to use `e.sterror` instead of `e[1]`.
Reported-by: John Snow
Signed-off-by: Eduardo Habkost
---
tests/image-fuzzer/runner.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/image-fuzzer/runner.py b/
On 10/16/19 12:41 PM, Sam Eiderman wrote:
>
> v1:
>
> Non-standard logical geometries break under QEMU.
>
> A virtual disk which contains an operating system which depends on
> logical geometries (consistent values being reported from BIOS INT13
> AH=08) will most likely break under QEMU/SeaB
Patchew URL: https://patchew.org/QEMU/20191021105350.1710-1-th...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PATCH v2 0/6] Enable more iotests during "make check-block"
Type: series
Message-id: 20191021105350.1710-1-th
Patchew URL: https://patchew.org/QEMU/20191021105350.1710-1-th...@redhat.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/
On 21.10.19 15:33, Max Reitz wrote:
> On 10.10.19 17:17, Max Reitz wrote:
>> Hi everyone,
>>
>> (CCs just based on tags in the commit in question)
>>
>> I have two bug reports which claim problems of qcow2 on XFS on ppc64le
>> machines since qemu 4.1.0. One of those is about bad performance
>> (so
On 18/10/2019 18.51, Bruce Rogers wrote:
> On Fri, 2019-10-18 at 18:10 +0200, Thomas Huth wrote:
>> Peter hit a "Could not open 'TEST_DIR/t.IMGFMT': Failed to get shared
>> 'write' lock - Is another process using the image
>> [TEST_DIR/t.IMGFMT]?"
>> error with 130 already twice. Looks like this te
On 10.10.19 17:17, Max Reitz wrote:
> Hi everyone,
>
> (CCs just based on tags in the commit in question)
>
> I have two bug reports which claim problems of qcow2 on XFS on ppc64le
> machines since qemu 4.1.0. One of those is about bad performance
> (sorry, is isn’t public :-/), the other about
On 21/10/2019 15.09, no-re...@patchew.org wrote:
> Patchew URL: https://patchew.org/QEMU/20191021105350.1710-1-th...@redhat.com/
>
>
>
> Hi,
>
> This series failed the docker-quick@centos7 build test. Please find the
> testing commands and
> their output below. If you have Docker installed, yo
Patchew URL: https://patchew.org/QEMU/20191021105350.1710-1-th...@redhat.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/
On 10/19/19 8:38 AM, Stefan Hajnoczi wrote:
The current libqos virtio-pci.c code implements the VIRTIO Legacy
interface. Extract existing code in preparation for VIRTIO 1.0 support.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Sergio Lopez
Reviewed-by: Thomas Huth
---
tests/libqos/virtio-
On 10/19/19 8:38 AM, Stefan Hajnoczi wrote:
The Legacy virtio-pci interface always uses BAR 0. VIRTIO 1.0 may need
to use a different BAR index, so make it configurable.
Signed-off-by: Stefan Hajnoczi
---
v3:
* Change uint8_t bar_idx to int [Thomas]
---
tests/libqos/virtio-pci.h | 2 ++
t
On 10/19/19 8:38 AM, Stefan Hajnoczi wrote:
Instead of just passing the vring page frame number, pass the full
QVirtQueue. This will allow the VIRTIO 1.0 transport to program the
fine-grained vring address registers in the future.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Sergio Lopez
Revie
On 10/19/19 8:37 AM, Stefan Hajnoczi wrote:
In VIRTIO 1.0 feature bits changed from 32-bit to 64-bit. (In fact, the
transports allow even more feature bits but nothing uses more than 64
bits today.)
Add 64-bit feature bit support to virtio-mmio and virtio-pci. This will
be necessary for VIRTIO
On 19/10/2019 08.38, Stefan Hajnoczi wrote:
> The Legacy virtio-pci interface always uses BAR 0. VIRTIO 1.0 may need
> to use a different BAR index, so make it configurable.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> v3:
> * Change uint8_t bar_idx to int [Thomas]
> ---
> tests/libqos/virtio-pc
On 19/10/2019 08.38, Stefan Hajnoczi wrote:
> VIRTIO 1.0 PCI devices have multiple PCI_CAP_ID_VNDR capabilities so we
> need a way to iterate over them. Extend qpci_find_capability() to take
> the last address.
>
> Signed-off-by: Stefan Hajnoczi
> --
> v3:
> * Document qpci_find_capability()
>
On 19/10/2019 08.38, Stefan Hajnoczi wrote:
> VIRTIO 1.0 uses little-endian for the vring. Legacy VIRTIO uses guest
> endianness. Adjust the code to handle both.
>
> Note that qvirtio_readq() is not defined because it has no users. All
> the other accessors are really needed.
>
> Signed-off-by
On 19/10/2019 08.38, Stefan Hajnoczi wrote:
> Device initialization has an extra step in VIRTIO 1.0. The FEATURES_OK
> status bit is set to indicate that feature negotiation has completed.
> The driver then reads the status register again to check that the device
> agrees with the final features.
On 19/10/2019 08.38, Stefan Hajnoczi wrote:
> According to VIRTIO 1.1 "3.1.1 Driver Requirements: Device
> Initialization", configuration space and virtqueues cannot be accessed
> before features have been negotiated. Enforce this requirement.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> tests/li
On 19/10/2019 08.38, Stefan Hajnoczi wrote:
> VIRTIO Device Initialization requires feature negotiation. The libqos
> virtio-9p driver lacks feature negotiation and is therefore
> non-compliant.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> tests/libqos/virtio-9p.c | 6 ++
> 1 file changed, 6
On 19/10/2019 08.37, Stefan Hajnoczi wrote:
> VIRTIO Device Initialization requires that feature negotiation has
> completed before virtqueues are set up. This makes sense because the
> driver must know whether it is operating in Legacy or VIRTIO 1.0 mode
> before it can access vring fields with t
On 19/10/2019 08.37, Stefan Hajnoczi wrote:
> VIRTIO Device Initialization requires feature negotiation. Currently
> virtio-scsi-test.c is non-compliant.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> tests/virtio-scsi-test.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/tests/v
On 11.10.19 09:49, Max Reitz wrote:
> On 10.10.19 18:15, Anton Nefedov wrote:
>> On 10/10/2019 6:17 PM, Max Reitz wrote:
>>> Hi everyone,
>>>
>>> (CCs just based on tags in the commit in question)
>>>
>>> I have two bug reports which claim problems of qcow2 on XFS on ppc64le
>>> machines since qemu
The next patch is going to add some python-based tests to the "auto"
group, and these tests require virtio-blk to work properly. Running
iotests without virtio-blk likely does not make too much sense anyway,
so instead of adding a check for the availability of virtio-blk to each
and every test (whi
When running 183 in Cirrus-CI on macOS, or with our vm-build-openbsd
target, it fails with an "Timeout waiting for return on handle 0" error.
Let's mark it as supported only on systems where the test is working
fine (i.e. Linux, FreeBSD and NetBSD).
Signed-off-by: Thomas Huth
---
tests/qemu-iot
Peter hit a "Could not open 'TEST_DIR/t.IMGFMT': Failed to get shared
'write' lock - Is another process using the image [TEST_DIR/t.IMGFMT]?"
error with 130 already twice. Looks like this test is a little bit
shaky, so for the time being, let's disable it from the "auto" group so
that it does not g
From: John Snow
verify_platform will check an explicit whitelist and blacklist instead.
The default will now be assumed to be allowed to run anywhere.
For tests that do not specify their platforms explicitly, this has the effect of
enabling these tests on non-linux platforms. For tests that alwa
According to Kevin, tests 030, 040 and 041 are among the most valuable
tests that we have, so we should always run them if possible, even if
they take a little bit longer.
According to Max, it would be good to have a test for iothreads and
migration. 127 and 256 seem to be good candidates for ioth
041 works fine on Linux, FreeBSD, NetBSD and OpenBSD, but fails on macOS.
Let's mark it as only supported on the systems where we know that it is
working fine.
Signed-off-by: Thomas Huth
---
tests/qemu-iotests/041 | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/qemu-i
As discussed here:
https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg00697.html
and here:
https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg01388.html
it would be good to have some more valuable iotests enabled in the
"auto" group to get better iotest coverage during "make check
On 19/10/2019 08.37, Stefan Hajnoczi wrote:
> In VIRTIO 1.0 feature bits changed from 32-bit to 64-bit. (In fact, the
> transports allow even more feature bits but nothing uses more than 64
> bits today.)
>
> Add 64-bit feature bit support to virtio-mmio and virtio-pci. This will
> be necessary
On 19/10/2019 08.37, Stefan Hajnoczi wrote:
> There was no real virtio-mmio ABI change between Legacy and VIRTIO 1.0
> except that the Version field was incremented from 1 to 2.
>
> However, QEMU does not allow Legacy drivers to perform VIRTIO 1.0
> operations like accessing 64-bit feature bits.
On 19/10/2019 08.37, Stefan Hajnoczi wrote:
> The VIRTIO Configuration Space cannot be accessed before device feature
> bits have been read because a driver doesn't know the endianness until
> it has checked VIRTIO_F_VERSION_1.
>
> Fix this problem in preparation for VIRTIO 1.0 support.
>
> Signe
On 18/10/2019 18.19, Max Reitz wrote:
> On 11.10.19 16:50, Thomas Huth wrote:
>> 041 works fine on Linux, FreeBSD and OpenBSD, so let's mark it as
>> only supported on these systems.
>>
>> Signed-off-by: Thomas Huth
>> ---
>> tests/qemu-iotests/041 | 3 ++-
>> 1 file changed, 2 insertions(+), 1 d
33 matches
Mail list logo
