From: Vladimir Sementsov-Ogievskiy
Implement reconnect. To achieve this:
1. add new modes:
connecting-wait: means, that reconnecting is in progress, and there
were small number of reconnect attempts, so all requests are
waiting for the connection.
connecting-nowait: reconnecting
From: Vladimir Sementsov-Ogievskiy
Add test, which starts backup to nbd target and restarts nbd server
during backup.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Message-Id: <20191009084158.15614-4-vsement...@virtuozzo.com>
Reviewed-by: Eric Blake
Signed-off-by: Eric Blake
---
tests/qemu-iot
On 10/9/19 3:41 AM, Vladimir Sementsov-Ogievskiy wrote:
Add test, which starts backup to nbd target and restarts nbd server
during backup.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/264| 95 +++
tests/qemu-iotests/264.out| 1
Thomas Huth writes:
> On 22/10/2019 15.48, Alex Bennée wrote:
>>
>> Max Reitz writes:
>>
>>> On 22.10.19 15:11, Alex Bennée wrote:
Thomas Huth writes:
> As discussed here:
>
> https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg00697.html
>
> and here:
On Thu, Oct 17, 2019 at 06:29:27PM -0300, Eduardo Habkost wrote:
> On Thu, Oct 17, 2019 at 05:11:29PM -0400, John Snow wrote:
> >
> >
> > On 10/16/19 3:24 PM, Eduardo Habkost wrote:
> > > This series ports image-fuzzer to Python 3.
> > >
> > > Eduardo Habkost (10):
> > > image-fuzzer: Open ima
From: Thomas Huth
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 s
From: Thomas Huth
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
Message-Id: <20191022072135.11188-3-th...@redhat.com>
---
tests/qemu-iotests/041 | 3 ++-
From: Thomas Huth
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
From: Thomas Huth
In the long term, we might want to add test 183 to the "auto" group
(but it still fails occasionally, so we cannot do that yet). However,
when running 183 in Cirrus-CI on macOS, or with our vm-build-openbsd
target, it currently always fails with an "Timeout waiting for return
on
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
Patchew URL: https://patchew.org/QEMU/20191022111738.20803-1-laur...@vivier.eu/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PATCH v14 0/9] hw/m68k: add Apple Machintosh Quadra 800 machine
Type: series
Message-id: 20191022111738.208
On 22/10/2019 15.48, Alex Bennée wrote:
>
> Max Reitz writes:
>
>> On 22.10.19 15:11, Alex Bennée wrote:
>>>
>>> Thomas Huth writes:
>>>
As discussed here:
https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg00697.html
and here:
https://lists.gnu.org/ar
On 22/10/2019 17.48, Stefan Hajnoczi wrote:
> On Mon, Oct 21, 2019 at 02:15:53PM +0200, Thomas Huth wrote:
>> 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
>>> bef
Stefan Hajnoczi writes:
[...]
> +static uint16_t qvirtio_readw(QVirtioDevice *d, QTestState *qts, uint64_t
> addr)
> +{
> +uint16_t val = qtest_readw(qts, addr);
> +
> +if (d->features & (1ull << VIRTIO_F_VERSION_1) && qtest_big_endian(qts))
> {
For my education, I was wondering why te
On Mon, Oct 21, 2019 at 02:23:15PM +0200, Thomas Huth wrote:
> 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 regis
On Mon, Oct 21, 2019 at 02:15:53PM +0200, Thomas Huth wrote:
> 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 thi
On Mon, Oct 21, 2019 at 02:48:08PM +0200, Thomas Huth wrote:
> 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
On Mon, Oct 21, 2019 at 02:08:34PM +0200, Thomas Huth wrote:
> 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.
Max Reitz writes:
> On 22.10.19 15:11, Alex Bennée wrote:
>>
>> Thomas Huth writes:
>>
>>> 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
>>
>> Queued
22.10.2019 15:56, Max Reitz wrote:
> On 22.10.19 14:23, Vladimir Sementsov-Ogievskiy wrote:
>> 22.10.2019 14:31, Max Reitz wrote:
>>> On 22.10.19 12:46, Vladimir Sementsov-Ogievskiy wrote:
22.10.2019 13:21, Andrey Shinkevich wrote:
>
> On 22/10/2019 12:28, Max Reitz wrote:
>> On 20
On 22/10/2019 15:56, Max Reitz wrote:
> On 22.10.19 14:23, Vladimir Sementsov-Ogievskiy wrote:
>> 22.10.2019 14:31, Max Reitz wrote:
>>> On 22.10.19 12:46, Vladimir Sementsov-Ogievskiy wrote:
22.10.2019 13:21, Andrey Shinkevich wrote:
>
> On 22/10/2019 12:28, Max Reitz wrote:
>>
On 22.10.19 15:11, Alex Bennée wrote:
>
> Thomas Huth writes:
>
>> 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
>
> Queued to testing/next, thanks.
It sho
On 22.10.2019 16:18, Max Reitz wrote:
> On 22.10.19 14:53, Denis Plotnikov wrote:
>> On 22.10.2019 14:05, Max Reitz wrote:
>>> On 21.10.19 08:50, Denis Plotnikov wrote:
On 18.10.2019 18:02, Max Reitz wrote:
> On 18.10.19 14:09, Denis Plotnikov wrote:
>> The modification is useful to w
On 22.10.19 14:53, Denis Plotnikov wrote:
>
> On 22.10.2019 14:05, Max Reitz wrote:
>> On 21.10.19 08:50, Denis Plotnikov wrote:
>>> On 18.10.2019 18:02, Max Reitz wrote:
On 18.10.19 14:09, Denis Plotnikov wrote:
> The modification is useful to workaround exclusive file access
> rest
Thomas Huth writes:
> 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
Queued to testing/next, thanks.
>
> it would be good to have some more valuable iotests enab
Le 22/10/2019 à 14:21, Philippe Mathieu-Daudé a écrit :
> Hi Laurent,
>
> On 10/22/19 1:17 PM, Laurent Vivier wrote:
>> There is no DMA in Quadra 800, so the CPU reads/writes the data from the
>> PDMA register (offset 0x100, ESP_PDMA in hw/m68k/q800.c) and copies them
>> to/from the memory.
>>
>>
Thomas Huth writes:
> On 22/10/2019 13.39, Alex Bennée wrote:
>>
>> Thomas Huth writes:
>>
>>> On 22/10/2019 09.21, Thomas Huth wrote:
As discussed here:
https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg00697.html
and here:
https://lists.gnu.org/arc
The function is definitely internal (it's not used by third party and
it has complicated interface). Move it to .c file.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/qemu/hbitmap.h | 30 --
util/hbitmap.c | 29 +
2 files
We are going to introduce bdrv_dirty_bitmap_next_dirty so that same
variable may be used to store its return value and to be its parameter,
so it would int64_t.
Similarly, we are going to refactor hbitmap_next_dirty_area to use
hbitmap_next_dirty together with hbitmap_next_zero, therefore we want
store_bitmap_data() loop does bdrv_set_dirty_iter() on each iteration,
which means that we actually don't need iterator itself and we can use
simpler bitmap API.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/qcow2-bitmap.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/qemu/hbitmap.h | 21
tests/test-hbitmap.c | 115 -
util/hbitmap.c | 16 --
3 files changed, 152 deletions(-)
diff --git a/include/qemu/hbitmap.h b/include/qemu/hbitmap.h
index
We have bdrv_dirty_bitmap_next_zero, let's add corresponding
bdrv_dirty_bitmap_next_dirty, which is more comfortable to use than
bitmap iterators in some cases.
For test modify test_hbitmap_next_zero_check_range to check both
next_zero and next_dirty and add some new checks.
Signed-off-by: Vladim
Hi!
The main feature here is improvement of _next_dirty_area API, which I'm
going to use then for backup / block-copy.
v2:
01: just use INT64_MAX instead of adding new constant
08: add separate function nbd_extent_array_convert_to_be and converted
state of NBDExtentArray, to make these things
Function is internal and even commented as internal. Drop its
definition from .h file.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/qemu/hbitmap.h | 7 ---
util/hbitmap.c | 2 +-
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/include/qemu/hbitmap.h b/include
Firstly, _next_dirty_area is for scenarios when we may contiguously
search for next dirty area inside some limited region, so it is more
comfortable to specify "end" which should not be recalculated on each
iteration.
Secondly, mirror wants to limit resulting are, and for this thing it
limits @cou
Introduce NBDExtentArray class, to handle extents list creation in more
controlled way and with less OUT parameters in functions.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
nbd/server.c | 201 ---
1 file changed, 109 insertions(+), 92 deletion
We have APIs which returns signed int64_t, to be able to return error.
Therefore we can't handle bitmaps with absolute size larger than
(INT64_MAX+1). Still, keep maximum to be INT64_MAX which is a bit
safer.
Note, that bitmaps are used to represent disk images, which can't
exceed INT64_MAX anyway
Use bdrv_dirty_bitmap_next_dirty_area for bitmap_to_extents. Since
bdrv_dirty_bitmap_next_dirty_area is very accurate in its interface,
we'll never exceed requested region with last chunk. So, we don't need
dont_fragment, and bitmap_to_extents() interface becomes clean enough
to not require any com
On 22.10.19 14:23, Vladimir Sementsov-Ogievskiy wrote:
> 22.10.2019 14:31, Max Reitz wrote:
>> On 22.10.19 12:46, Vladimir Sementsov-Ogievskiy wrote:
>>> 22.10.2019 13:21, Andrey Shinkevich wrote:
On 22/10/2019 12:28, Max Reitz wrote:
> On 20.10.19 22:37, Andrey Shinkevich wrote:
On 22.10.2019 14:05, Max Reitz wrote:
> On 21.10.19 08:50, Denis Plotnikov wrote:
>> On 18.10.2019 18:02, Max Reitz wrote:
>>> On 18.10.19 14:09, Denis Plotnikov wrote:
The modification is useful to workaround exclusive file access
restrictions,
e.g. to implement VM migration with
22.10.2019 14:31, Max Reitz wrote:
> On 22.10.19 12:46, Vladimir Sementsov-Ogievskiy wrote:
>> 22.10.2019 13:21, Andrey Shinkevich wrote:
>>>
>>> On 22/10/2019 12:28, Max Reitz wrote:
On 20.10.19 22:37, Andrey Shinkevich wrote:
> To inform the block layer about writing all the data compres
Hi Laurent,
On 10/22/19 1:17 PM, Laurent Vivier wrote:
There is no DMA in Quadra 800, so the CPU reads/writes the data from the
PDMA register (offset 0x100, ESP_PDMA in hw/m68k/q800.c) and copies them
to/from the memory.
There is a nice assembly loop in the kernel to do that, see
linux/drivers/
On 22/10/2019 13.39, Alex Bennée wrote:
>
> Thomas Huth writes:
>
>> On 22/10/2019 09.21, Thomas Huth wrote:
>>> 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/msg013
Thomas Huth writes:
> On 22/10/2019 09.21, Thomas Huth wrote:
>> 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 valu
Inside the 680x0 Macintosh, VIA (Versatile Interface Adapter) is used
to interface the keyboard, Mouse, and real-time clock. It also provides
control line for the floppy disk driver, video interface, sound circuitry
and serial interface.
This implementation is based on the MOS6522 object.
Co-deve
This is needed by Quadra 800, this card can run on little-endian
or big-endian bus.
Signed-off-by: Laurent Vivier
Tested-by: Hervé Poussineau
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Hervé Poussineau
---
hw/net/dp8393x.c | 88 +++-
1 file ch
On 22.10.19 12:46, Vladimir Sementsov-Ogievskiy wrote:
> 22.10.2019 13:21, Andrey Shinkevich wrote:
>>
>> On 22/10/2019 12:28, Max Reitz wrote:
>>> On 20.10.19 22:37, Andrey Shinkevich wrote:
To inform the block layer about writing all the data compressed, we
introduce the 'compress' comm
If you want to test the machine, it doesn't yet boot a MacROM, but you can
boot a linux kernel from the command line.
You can install your own disk using debian-installer with:
./qemu-system-m68k \
-M q800 \
-serial none -serial mon:stdio \
-m 1000M -drive file=m68k.qcow2,format=q
VIA needs to be able to poll the ADB interface and to read/write data
from/to the bus.
This patch adds functions allowing that.
Co-developed-by: Mark Cave-Ayland
Signed-off-by: Mark Cave-Ayland
Signed-off-by: Laurent Vivier
Reviewed-by: Hervé Poussineau
Reviewed-by: Thomas Huth
---
include/
There is no DMA in Quadra 800, so the CPU reads/writes the data from the
PDMA register (offset 0x100, ESP_PDMA in hw/m68k/q800.c) and copies them
to/from the memory.
There is a nice assembly loop in the kernel to do that, see
linux/drivers/scsi/mac_esp.c:MAC_ESP_PDMA_LOOP().
The start of the tran
From: Philippe Mathieu-Daudé
This test boots a Linux kernel on a Quadra 800 board
and verify the serial is working.
Example:
$ avocado --show=app,console run -t machine:q800
tests/acceptance/boot_linux_console.py
console: ABCFGHIJK
console: Linux version 5.2.0-2-m68k (debian-ker...@lists
SWIM (Sander-Wozniak Integrated Machine) is the floppy controller of
the 680x0 Macintosh.
This patch introduces only the basic support: it allows to switch from
IWM (Integrated WOZ Machine) mode to the SWIM mode and makes the linux
driver happy.
It cannot read any floppy image.
Co-developed-by:
This patch adds basic support for the NuBus bus. This is used by 680x0
Macintosh.
Co-developed-by: Mark Cave-Ayland
Signed-off-by: Mark Cave-Ayland
Signed-off-by: Laurent Vivier
Reviewed-by: Thomas Huth
---
include/hw/nubus/mac-nubus-bridge.h | 24
include/hw/nubus/nubus.h|
I'm rebasing some of these patches for seven years now,
too many years...
if you want to test the machine, I'm sorry, it doesn't boot
a MacROM, but you can boot a linux kernel from the command line.
You can install your own disk using debian-installer, with:
...
-M q800 \
-serial non
This patch adds support for a graphic framebuffer device.
This device can be added as a sysbus device or as a NuBus device.
It is accessed as a framebuffer but the color palette can be set.
Co-developed-by: Mark Cave-Ayland
Signed-off-by: Mark Cave-Ayland
Signed-off-by: Laurent Vivier
Reviewed
No reason to limit buffered copy to one cluster. Let's allow up to 1
MiB.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Max Reitz
---
include/block/block-copy.h | 2 +-
block/block-copy.c | 48 +-
2 files changed, 33 insertions(+), 17 dele
Move bounce_buffer allocation block_copy_with_bounce_buffer. This
commit simplifies further work on implementing copying by larger chunks
(of different size) and further asynchronous handling of block_copy
iterations (with help of block/aio_task API).
Allocation works fast, a lot faster than disk
Currently total allocation for parallel requests to block-copy instance
is unlimited. Let's limit it to 128 MiB.
For now block-copy is used only in backup, so actually we limit total
allocation for backup job.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Max Reitz
---
include/block
Merge copying code into one function block_copy_do_copy, which only
calls bdrv_ io functions and don't do any synchronization (like dirty
bitmap set/reset).
Refactor block_copy() function so that it takes full decision about
size of chunk to be copied and does all the synchronization (checking
int
Introduce an API for some shared splittable resource, like memory.
It's going to be used by backup. Backup uses both read/write io and
copy_range. copy_range may consume memory implictly, so the new API is
abstract: it doesn't allocate any real memory but only hands out
tickets.
The idea is that w
I'm going to bring block-status driven, async copying process to
block-copy, to make it fast. The first step is to limit memory usage of
backup, here is it.
v3:
03: add Max's r-b
04: fix commit message and include guards, add Max's r-b
05-06: add Max's r-b
v2: [mostly by Max's comments]
Now based
Large copy range may imply memory allocation and large io effort, so
using 2G copy range request may be bad idea. Let's limit it to 16 MiB.
It also helps the following patch to refactor copy-with-offload
fallback to copy-with-bounce-buffer.
Note, that total memory usage of backup is still not limi
On 21.10.19 08:50, Denis Plotnikov wrote:
>
> On 18.10.2019 18:02, Max Reitz wrote:
>> On 18.10.19 14:09, Denis Plotnikov wrote:
>>> The modification is useful to workaround exclusive file access restrictions,
>>> e.g. to implement VM migration with shared disk stored on a storage with
>>> the exc
22.10.2019 13:23, Max Reitz wrote:
> On 16.10.19 19:09, Vladimir Sementsov-Ogievskiy wrote:
>> Introduce an API for some shared splittable resource, like memory.
>> It's going to be used by backup. Backup uses both read/write io and
>> copy_range. copy_range may consume memory implictly, so the new
22.10.2019 13:21, Andrey Shinkevich wrote:
>
> On 22/10/2019 12:28, Max Reitz wrote:
>> On 20.10.19 22:37, Andrey Shinkevich wrote:
>>> To inform the block layer about writing all the data compressed, we
>>> introduce the 'compress' command line option. Based on that option, the
>>> written data w
On 16.10.19 19:09, Vladimir Sementsov-Ogievskiy wrote:
> No reason to limit buffered copy to one cluster. Let's allow up to 1
> MiB.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> include/block/block-copy.h | 2 +-
> block/block-copy.c | 48 +
On 10/16/19 6:41 PM, Sam Eiderman wrote:
From: Sam Eiderman
Using fw_cfg, supply logical CHS values directly from QEMU to the BIOS.
Non-standard logical geometries break under QEMU.
A virtual disk which contains an operating system which depends on
logical geometries (consistent values being
On 10/16/19 6:41 PM, Sam Eiderman wrote:
From: Sam Eiderman
Move device name construction to a separate function.
We will reuse this function in the following commit to pass logical CHS
parameters through fw_cfg much like we currently pass bootindex.
Reviewed-by: Karl Heubaum
Reviewed-by: Ar
On 16.10.19 19:09, Vladimir Sementsov-Ogievskiy wrote:
> Currently total allocation for parallel requests to block-copy instance
> is unlimited. Let's limit it to 128 MiB.
>
> For now block-copy is used only in backup, so actually we limit total
> allocation for backup job.
>
> Signed-off-by: Vla
On 10/16/19 6:41 PM, Sam Eiderman wrote:
From: Sam Eiderman
Relevant devices are:
* ide-hd (and ide-cd, ide-drive)
* scsi-hd (and scsi-cd, scsi-disk, scsi-block)
* virtio-blk-pci
We do not call del_boot_device_lchs() for ide-* since we don't need to -
IDE block devices do not su
On 16.10.19 19:09, Vladimir Sementsov-Ogievskiy wrote:
> Introduce an API for some shared splittable resource, like memory.
> It's going to be used by backup. Backup uses both read/write io and
> copy_range. copy_range may consume memory implictly, so the new API is
> abstract: it doesn't allocate
On 10/16/19 6:41 PM, Sam Eiderman wrote:
From: Sam Eiderman
We will need to add LCHS removal logic to scsi-hd's unrealize() in the
next commit.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
--
On 10/16/19 6:41 PM, Sam Eiderman wrote:
From: Sam Eiderman
Add an interface to provide direct logical CHS values for boot devices.
We will use this interface in the next commits.
Reviewed-by: Karl Heubaum
Reviewed-by: Arbel Moshe
Signed-off-by: Sam Eiderman
Signed-off-by: Sam Eiderman
---
On 22/10/2019 12:28, Max Reitz wrote:
> On 20.10.19 22:37, Andrey Shinkevich wrote:
>> To inform the block layer about writing all the data compressed, we
>> introduce the 'compress' command line option. Based on that option, the
>> written data will be aligned by the cluster size at the generic l
On 10/16/19 6:41 PM, Sam Eiderman wrote:
From: Sam Eiderman
Add logical geometry variables to BlockConf.
A user can now supply "lcyls", "lheads" & "lsecs" for any HD device
that supports CHS ("cyls", "heads", "secs").
These devices include:
* ide-hd
* scsi-hd
* virtio-blk-pci
On 16.10.19 19:09, Vladimir Sementsov-Ogievskiy wrote:
> Merge copying code into one function block_copy_do_copy, which only
> calls bdrv_ io functions and don't do any synchronization (like dirty
> bitmap set/reset).
>
> Refactor block_copy() function so that it takes full decision about
> size o
On 20.10.19 22:37, Andrey Shinkevich wrote:
> Add a case to the iotest #030 that tests the 'compress' option for a
> block-stream job.
>
> Signed-off-by: Andrey Shinkevich
> ---
> tests/qemu-iotests/030 | 34 +-
> tests/qemu-iotests/030.out | 4 ++--
> 2 file
On 20.10.19 22:37, Andrey Shinkevich wrote:
> To inform the block layer about writing all the data compressed, we
> introduce the 'compress' command line option. Based on that option, the
> written data will be aligned by the cluster size at the generic layer.
>
> Suggested-by: Roman Kagan
> Sugg
On 22/10/2019 09.21, Thomas Huth wrote:
> 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
> "
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
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
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
In the long term, we might want to add test 183 to the "auto" group
(but it still fails occasionally, so we cannot do that yet). However,
when running 183 in Cirrus-CI on macOS, or with our vm-build-openbsd
target, it currently always fails with an "Timeout waiting for return
on handle 0" error.
L
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
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
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
86 matches
Mail list logo
