08.10.2019 12:05, Vladimir Sementsov-Ogievskiy wrote:
> 07.10.2019 23:21, Eric Blake wrote:
>> On 10/7/19 11:04 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> Make it more obvious how to add new fields to the version 3 header and
>>> how to interpret them.
>>>
>>> Signed-off-by: Vladimir Sementsov-Ogi
Hi Vladimir,
On Thu, Oct 17, 2019 at 05:21:22PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> After commit 00e30f05de1d195, there is no more "goto error" points
> after job creation, so after "error:" @job is always NULL and we don't
> need roll-back job creation.
I don't know this code very well,
On 18.10.19 08:20, Thomas Huth wrote:
> On 17/10/2019 18.41, Peter Maydell wrote:
>> On Fri, 27 Sep 2019 at 17:44, Max Reitz wrote:
>>>
>>> On 27.09.19 18:39, Peter Maydell wrote:
Hi; I just saw this iotest failure (on an s390x box, as it happens):
TESTiotest-qcow2: 130 [fail]
On 17.10.19 16:52, Eric Blake wrote:
> On 10/17/19 8:31 AM, Max Reitz wrote:
>> Unix sockets generally have a maximum path length. Depending on your
>> $TEST_DIR, it may be exceeded and then all tests that create and use
>> Unix sockets there may fail.
>>
>> Circumvent this by adding a new scratch
18.10.2019 11:29, Vladimir Sementsov-Ogievskiy wrote:
> 08.10.2019 12:05, Vladimir Sementsov-Ogievskiy wrote:
>> 07.10.2019 23:21, Eric Blake wrote:
>>> On 10/7/19 11:04 AM, Vladimir Sementsov-Ogievskiy wrote:
Make it more obvious how to add new fields to the version 3 header and
how to i
The patch add new additional field to qcow2 header: compression_type,
which specifies compression type. If field is absent or zero, default
compression type is set: ZLIB, which corresponds to current behavior.
New compression type (ZSTD) is to be added in further commit.
Suggested-by: Denis Plotn
Hi all!
Here is my proposal, about how to correctly update qcow2 specification
to introduce new field, keeping in mind currently existing images and
downstream Qemu instances.
v8: Add padding, and clarify "zero equals absence" concept.
Move some points to commit message from the spec itself.
Make it more obvious how to add new fields to the version 3 header and
how to interpret them.
The specification is adjusted so for new defined optional fields:
1. Software may support some of these optional fields and ignore the
others, which means that features may be backported to downstream
Header extensions ends are already defined to be multiply of 8. Let's
gently ask for header length to be a multiply of 8 too, when we have
some additional fields. Requiring this may be considered as an
incompatible change, so the padding is optional. Actually, padding is
allowed before this patch (
On 18/10/2019 10.42, Max Reitz wrote:
> On 18.10.19 08:20, Thomas Huth wrote:
>> On 17/10/2019 18.41, Peter Maydell wrote:
>>> On Fri, 27 Sep 2019 at 17:44, Max Reitz wrote:
On 27.09.19 18:39, Peter Maydell wrote:
> Hi; I just saw this iotest failure (on an s390x box, as it happens):
Some tests in 118 use chmod to remove write permissions from the file
and assume that the image can indeed not be opened read-write
afterwards. This doesn't work when the test is run as root, because root
can still open the file as writable even when the permission bit isn't
set.
Introduce a @skip
We added more generic options after introducing -blockdev and forgot to
update the documentation (man page and --help output) accordingly. Do
that now.
Signed-off-by: Kevin Wolf
---
qemu-options.hx | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/qemu-op
On Fri, 18 Oct 2019 at 13:02, Kevin Wolf wrote:
>
> We added more generic options after introducing -blockdev and forgot to
> update the documentation (man page and --help output) accordingly. Do
> that now.
>
> Signed-off-by: Kevin Wolf
> ---
> qemu-options.hx | 22 +-
> 1 f
Am 17.10.2019 um 16:21 hat Vladimir Sementsov-Ogievskiy geschrieben:
> After commit 00e30f05de1d195, there is no more "goto error" points
> after job creation, so after "error:" @job is always NULL and we don't
> need roll-back job creation.
>
> Reported-by: Coverity (CID 1406402)
> Signed-off-by:
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 exclusive file opening model: a destination VM is started waiting for
incomming migration with a fake image drive, and later, on the last migrati
Hi Kevin,
On 10/18/19 1:51 PM, Kevin Wolf wrote:
Some tests in 118 use chmod to remove write permissions from the file
and assume that the image can indeed not be opened read-write
afterwards. This doesn't work when the test is run as root, because root
can still open the file as writable even w
On Thu, 17 Oct 2019 at 22:54, John Snow wrote:
>
> The following changes since commit f22f553efffd083ff624be116726f843a39f1148:
>
> Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20191013' into
> staging (2019-10-17 16:48:56 +0100)
>
> are available in the Git repository at:
>
> http
On 10/18/19 4:03 AM, Max Reitz wrote:
-if [ ! -e "$TEST_DIR" ]; then
- mkdir "$TEST_DIR"
+tmp_sock_dir=false
+if [ -z "$SOCK_DIR" ]; then
+ SOCK_DIR=$(mktemp -d)
+ tmp_sock_dir=true
fi
+mkdir -p "$SOCK_DIR" || _init_error 'Failed to create SOCK_DIR'
Thinking about this again
On 10/18/19 4:27 AM, Vladimir Sementsov-Ogievskiy wrote:
I would suggest a stronger requirement:
header_length must be a multiple of 4, and must not land in the middle of any
optional 8-byte field.
Or maybe even add our compression type extension with 4 bytes of padding, so
that we could go
On 10/18/19 4:47 AM, Vladimir Sementsov-Ogievskiy wrote:
The patch add new additional field to qcow2 header: compression_type,
which specifies compression type. If field is absent or zero, default
compression type is set: ZLIB, which corresponds to current behavior.
New compression type (ZSTD) i
On 10/18/19 4:47 AM, Vladimir Sementsov-Ogievskiy wrote:
Header extensions ends are already defined to be multiply of 8. Let's
gently ask for header length to be a multiply of 8 too, when we have
some additional fields. Requiring this may be considered as an
incompatible change, so the padding is
On 10/18/19 4:47 AM, Vladimir Sementsov-Ogievskiy wrote:
Make it more obvious how to add new fields to the version 3 header and
how to interpret them.
The specification is adjusted so for new defined optional fields:
The specification is adjusted to make it clear that future fields are
option
[cc qemu-block]
On 10/18/19 4:59 AM, Han Han wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1763105
Signed-off-by: Han Han
---
qemu-img.texi | 10 ++
1 file changed, 10 insertions(+)
Reviewed-by: Eric Blake
diff --git a/qemu-img.texi b/qemu-img.texi
index b5156d6316..44596
18.10.2019 16:39, Eric Blake wrote:
> On 10/18/19 4:27 AM, Vladimir Sementsov-Ogievskiy wrote:
>
> I would suggest a stronger requirement:
>
> header_length must be a multiple of 4, and must not land in the middle of
> any optional 8-byte field.
>
> Or maybe even add our c
Am 18.10.2019 um 14:59 hat Philippe Mathieu-Daudé geschrieben:
> Hi Kevin,
>
> On 10/18/19 1:51 PM, Kevin Wolf wrote:
> > Some tests in 118 use chmod to remove write permissions from the file
> > and assume that the image can indeed not be opened read-write
> > afterwards. This doesn't work when t
On 10/18/19 7:09 AM, 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 exclusive file opening model: a destination VM is started waiting for
incomming migration with a fa
18.10.2019 17:00, Eric Blake wrote:
> On 10/18/19 4:47 AM, Vladimir Sementsov-Ogievskiy wrote:
>> Make it more obvious how to add new fields to the version 3 header and
>> how to interpret them.
>>
>> The specification is adjusted so for new defined optional fields:
>
> The specification is adjust
18.10.2019 17:02, Eric Blake wrote:
> On 10/18/19 4:47 AM, Vladimir Sementsov-Ogievskiy wrote:
>> Header extensions ends are already defined to be multiply of 8. Let's
>> gently ask for header length to be a multiply of 8 too, when we have
>> some additional fields. Requiring this may be considered
18.10.2019 17:04, Eric Blake wrote:
> On 10/18/19 4:47 AM, Vladimir Sementsov-Ogievskiy wrote:
>> The patch add new additional field to qcow2 header: compression_type,
>> which specifies compression type. If field is absent or zero, default
>> compression type is set: ZLIB, which corresponds to cur
On 10/18/19 4:27 PM, Kevin Wolf wrote:
Am 18.10.2019 um 14:59 hat Philippe Mathieu-Daudé geschrieben:
Hi Kevin,
On 10/18/19 1:51 PM, Kevin Wolf wrote:
Some tests in 118 use chmod to remove write permissions from the file
and assume that the image can indeed not be opened read-write
afterwards.
On 18.10.19 16:27, Kevin Wolf wrote:
> Am 18.10.2019 um 14:59 hat Philippe Mathieu-Daudé geschrieben:
>> Hi Kevin,
>>
>> On 10/18/19 1:51 PM, Kevin Wolf wrote:
>>> Some tests in 118 use chmod to remove write permissions from the file
>>> and assume that the image can indeed not be opened read-write
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 exclusive file opening model: a destination VM is started waiting for
> incomming migration with
On 11.10.19 11:07, Vladimir Sementsov-Ogievskiy wrote:
> Passing zero length to these functions leads to unpredicted results.
> Zero-length set/reset may occur in active-mirror, on zero-length write
> (which is unlikely, but not guaranteed to never happen).
>
> Let's just do nothing on zero-length
On 11.10.19 11:07, Vladimir Sementsov-Ogievskiy wrote:
> Commit 9adc1cb49af8d fixed a bug about unaligned (to dirty bitmap
> granularity) guest writes (and discards) by simply requesting
> corresponding alignment on mirror-top filter. However forcing large
> alignment obviously decreases performanc
On 11.10.19 11:07, Vladimir Sementsov-Ogievskiy wrote:
> Prior 9adc1cb49af8d do_sync_target_write had a bug: it reset aligned-up
> region in the dirty bitmap, which means that we may not copy some bytes
> and assume them copied, which actually leads to producing corrupted
> target.
>
> So 9adc1cb4
On 17.10.19 15:31, Max Reitz wrote:
> Hi,
>
> Perhaps the main reason we cannot run important tests such as 041 in CI
> is that when they care Unix sockets in $TEST_DIR, the path may become
> too long to connect to them.
>
> To get by this problem, this series lets the check script create a new
>
09.10.2019 20:02, Eric Blake wrote:
> On 9/30/19 10:15 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 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/s
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, and currently nobody has a real clue what could be causing this
issue, so for the t
18.10.2019 18:54, Max Reitz wrote:
> On 11.10.19 11:07, Vladimir Sementsov-Ogievskiy wrote:
>> Commit 9adc1cb49af8d fixed a bug about unaligned (to dirty bitmap
>> granularity) guest writes (and discards) by simply requesting
>> corresponding alignment on mirror-top filter. However forcing large
>>
On 11.10.19 16:50, Thomas Huth wrote:
> 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
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 deletion(-)
>
> diff --git a/tests/qemu-iotest
On 10/18/19 11:07 AM, Vladimir Sementsov-Ogievskiy wrote:
static int nbd_co_send_extents(NBDClient *client, uint64_t handle,
- NBDExtent *extents, unsigned int nb_extents,
- uint64_t length, bool last,
-
Am 18.10.2019 um 17:00 hat Max Reitz geschrieben:
> On 18.10.19 16:27, Kevin Wolf wrote:
> > Am 18.10.2019 um 14:59 hat Philippe Mathieu-Daudé geschrieben:
> >> Hi Kevin,
> >>
> >> On 10/18/19 1:51 PM, Kevin Wolf wrote:
> >>> Some tests in 118 use chmod to remove write permissions from the file
> >
On 10/17/19 7:17 AM, Max Reitz wrote:
Why haven't we noticed the failure? Because the test rarely gets run:
'./check -qcow2 173' is insufficient (that defaults to using file protocol)
'./check -nfs 173' is insufficient (that defaults to using raw format)
so the test is only run with:
./check -qc
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 test is a little bit
> shaky, and currently nobod
On 11.10.19 16:50, Thomas Huth wrote:
> 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 availabi
On 11.10.19 16:50, Thomas Huth wrote:
> 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
> migratio
On Sat, 5 Oct 2019 15:05:23 +0200
Lukas Straub wrote:
> After failover the Secondary side of replication shouldn't change state,
> because
> it now functions as our primary disk.
>
> In replication_start, replication_do_checkpoint, replication_stop, ignore
> the request if current state is BLOCK
CC qemu-block
On 10/18/19 5:59 AM, Han Han wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1763105
>
> Signed-off-by: Han Han
> ---
> qemu-img.texi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/qemu-img.texi b/qemu-img.texi
> index b5156d6316..44596c2d93 100644
> --
On 10/18/19 12:10 PM, 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 test is a little bit
> shaky, and currently nobody has a real
Hi,
Today while working with two different Windows Server 2012 R2 guests I found
that when I try to attach an ISO file to a SCSI CD-ROM device through libvirt
(virsh or virt-manager) while the guest is running, qemu crashes and the
following message is logged:
Assertion failed: blk_get_aio_con
Hi,
Today while working with two different Windows Server 2012 R2 guests I
found that when I try to attach an ISO file to a SCSI CD-ROM device
through libvirt (virsh or virt-manager) while the guest is running,
qemu crashes and the following message is logged:
Assertion failed: blk_get_aio_con
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.
Signed-off-by: Stefan Hajnoczi
---
tests/virtio-blk-test.c |
v3:
* Now implements VIRTIO 1.0 fully (vring, device initialization).
This required several new patches to address the following issues:
1. Tests that do not negotiate features (non-compliant!)
2. Tests that access configuration space before feature negotiation
(non-compliant!)
3
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. Since we will introduce
64-bit feature bit support we
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 1.0 support.
Signed-off-by: Stefan Hajnoczi
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 the correct endianness.
Signed-off-by: Stefan Hajnoc
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/virtio-scsi-test.c b/tests/virtio-scsi-test.c
index 7c8f9b27f8.
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 insertions(+)
diff --git a/tests/libqos/virtio-9p.c b/tests
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: Stefan Hajnoczi
---
tests/libqos/virtio.h | 4 +
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/libqos/virtio.c | 11 +++
1 file changed, 11 inserti
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.
Implement this step as part of qvirtio_set_features
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()
---
tests/libqos/pci.h | 2 +-
tests/libqos/pci.c | 30 +
The MSI-X vectors are programmed differently in the VIRTIO 1.0 and
Legacy interfaces. Introduce callbacks so different implementations can
be used depending on the interface version.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Sergio Lopez
Reviewed-by: Thomas Huth
---
tests/libqos/virtio-pci.
Implement the VIRTIO 1.0 virtio-pci interface. The main change here is
that the register layout is no longer a fixed layout in BAR 0. Instead
we have to iterate of PCI Capabilities to find descriptions of where
various registers are located. The vring registers are also more
fine-grained, allowi
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
Reviewed-by: Thomas Huth
---
tests/libqos/virtio.
The VIRTIO 1.0 code will need to perform additional steps but it will
reuse the common virtqueue setup/cleanup code. Make these functions
public.
Make sure to invoke callbacks via QVirtioBus instead of directly calling
the virtio-pci Legacy versions of these functions.
Signed-off-by: Stefan Hajn
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 ++
tests/libqos/virtio-pci.c | 3 ++-
2 files changed
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-pci.h | 2 --
tests/libqos/virtio-pci.c | 29 +++
69 matches
Mail list logo
