On 10/06/2017 08:50 PM, Philippe Mathieu-Daudé wrote:
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> block/qcow2.c | 2 +-
> block/vhdx.c | 9 +
> 2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/block/qcow2.c b/block/qcow2.c
> index f63d1831f8..3e7d6c81be 100644
> ---
From: Jan Beulich
Prefer g_new() / g_new0() to be farther backwards compatible with older
glib versions. As there's no point in zeroing the allocation here (the
loop right afterwards fully initializes the memory), use the former.
Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
Acked-by: A
Signed-off-by: Philippe Mathieu-Daudé
---
block/qcow2.c | 2 +-
block/vhdx.c | 9 +
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index f63d1831f8..3e7d6c81be 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -2738,7 +2738,7 @@ static int qc
Signed-off-by: Philippe Mathieu-Daudé
---
hw/block/nvme.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 9aa32692a3..ff712fa8cc 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -454,7 +454,7 @@ static uint16_t nvme_create_sq(Nv
Signed-off-by: Philippe Mathieu-Daudé
---
block/backup.c | 2 +-
block/blkdebug.c | 4 ++--
block/commit.c | 2 +-
block/linux-aio.c | 2 +-
block/mirror.c | 2 +-
block/qapi.c | 4 ++--
block/qcow2-refcount.c | 12 +---
block/qed-l2-cach
From: Marc-André Lureau
Signed-off-by: Marc-André Lureau
Signed-off-by: Philippe Mathieu-Daudé
[PMD: split of some files in other commits of the same series, add libqtest.c]
---
tests/ahci-test.c | 4 ++--
tests/fw_cfg-test.c | 4 ++--
tests/libqos/ahci.c | 2 +-
tests/libqos/libqos.c
From: Marc-André Lureau
Signed-off-by: Marc-André Lureau
---
block/iscsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index 4683f3b244..f9f910168d 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -1001,7 +1001,7 @@ static BlockAIOCB *iscsi
From: Marc-André Lureau
Signed-off-by: Marc-André Lureau
Signed-off-by: Philippe Mathieu-Daudé
[PMD: squashed tests/test-hbitmap.c changes]
---
tests/test-hbitmap.c | 2 +-
util/hbitmap.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/test-hbitmap.c b/tests/
On 6 October 2017 at 16:53, Kevin Wolf wrote:
> The following changes since commit a26a98dfb9d448d7234d931ae3720feddf6f0651:
>
> Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20171006' into
> staging (2017-10-06 13:19:03 +0100)
>
> are available in the
From: Pavel Butsykin
Now after shrinking the image, at the end of the image file, there might be a
tail that probably will never be used. So we can find the last used cluster and
cut the tail.
Signed-off-by: Pavel Butsykin
Reviewed-by: John Snow
Message-id: 20170929121613.25997-3-pbutsy...@vir
From: Vladimir Sementsov-Ogievskiy
Backing may be zero after failed bdrv_append in mirror_start_job,
which leads to SIGSEGV.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Message-id: 20170929152255.5431-1-vsement...@virtuozzo.com
Signed-off-by: Max Reitz
---
block/mirror.c | 4
1 file chan
From: "Daniel P. Berrange"
The BDRV_REQ_FUA flag can trivially be allowed in the crypt driver
as a passthrough to the underlying block driver.
Reviewed-by: Max Reitz
Reviewed-by: Eric Blake
Signed-off-by: Daniel P. Berrange
Message-id: 20170927125340.12360-7-berra...@redhat.com
Signed-off-by:
From: Pavel Butsykin
Signed-off-by: Pavel Butsykin
Reviewed-by: Eric Blake
Reviewed-by: John Snow
Reviewed-by: Max Reitz
Message-id: 20170929121613.25997-2-pbutsy...@virtuozzo.com
Signed-off-by: Max Reitz
---
block/qcow2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --gi
From: "Daniel P. Berrange"
Instead of sector offset, take the bytes offset when encrypting
or decrypting data.
Signed-off-by: Daniel P. Berrange
Message-id: 20170927125340.12360-6-berra...@redhat.com
Reviewed-by: Eric Blake
Reviewed-by: Max Reitz
Signed-off-by: Max Reitz
---
crypto/blockpri
From: Vladimir Sementsov-Ogievskiy
Backing may be zero after failed bdrv_attach_child in
bdrv_set_backing_hd, which leads to SIGSEGV.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Message-id: 20170928120300.58164-1-vsement...@virtuozzo.com
Reviewed-by: John Snow
Signed-off-by: Max Reitz
---
bl
From: "Daniel P. Berrange"
The crypto APIs report the offset of the data payload as an uint64_t
type, but the block driver is casting to size_t or ssize_t which will
potentially truncate.
Most of the block APIs use int64_t for offsets meanwhile, so even if
using uint64_t in the crypto block driv
From: Eric Blake
Add a test for qcow2 copy-on-read behavior, including exposure
for the just-fixed bugs.
The copy-on-read behavior is always to a qcow2 image, but the
test is careful to allow running with most image protocol/format
combos as the backing file being copied from (luks being the
exc
From: Eric Blake
Improve our braindead copy-on-read implementation. Pre-patch,
we have multiple issues:
- we create a bounce buffer and perform a write for the entire
request, even if the active image already has 99% of the
clusters occupied, and really only needs to copy-on-read the
remaining 1
We don't need to make any assumptions about the graph layout above the
top node of the commit operation any more. Remove the use of
bdrv_find_overlay() and related variables from the commit job code.
bdrv_drop_intermediate() doesn't use the 'active' parameter any more, so
we can just drop it.
The
From: Eric Blake
Handle a 0-length block status request up front, with a uniform
return value claiming the area is not allocated.
Most callers don't pass a length of 0 to bdrv_get_block_status()
and friends; but it definitely happens with a 0-length read when
copy-on-read is enabled. While we c
From: Eric Blake
Make it possible to inject errors on writes performed during a
read operation due to copy-on-read semantics.
Signed-off-by: Eric Blake
Reviewed-by: Jeff Cody
Reviewed-by: Kevin Wolf
Reviewed-by: John Snow
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Kevin Wolf
---
qapi/blo
From: "Daniel P. Berrange"
Make the crypto driver implement the bdrv_co_preadv|pwritev
callbacks, and also use bdrv_co_preadv|pwritev for I/O
with the protocol driver beneath. This replaces sector based
I/O with byte based I/O, and allows us to stop assuming the
physical sector size matches the e
From: Max Reitz
do_run_qemu() in iotest 195 first applies _filter_imgfmt when printing
qemu's command line and _filter_testdir only afterwards. Therefore, if
the image format is part of the test directory path, _filter_testdir
will no longer apply and the actual output will differ from the
refer
From: "Daniel P. Berrange"
Using 16KB bounce buffers creates a significant performance
penalty for I/O to encrypted volumes on storage which high
I/O latency (rotating rust & network drives), because it
triggers lots of fairly small I/O operations.
On tests with rotating rust, and cache=none|dir
From: Paolo Bonzini
The variable is almost unused, and one of the two uses is actually
uninitialized.
Signed-off-by: Paolo Bonzini
Reviewed-by: Eric Blake
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/check | 5 +
tests/qemu-iotests/common.rc | 2 +-
2 files changed, 2 insertions(
From: Paolo Bonzini
These are never used by "check", with one exception that does not need
$QEMU_OPTIONS. Keep them in common.rc, which will be soon included only
by the tests.
Signed-off-by: Paolo Bonzini
Reviewed-by: Eric Blake
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/039.out
From: Paolo Bonzini
The variable is used in "common" but defined only after the file
is sourced.
Signed-off-by: Paolo Bonzini
Reviewed-by: Eric Blake
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/check | 2 --
tests/qemu-iotests/common | 2 ++
2 files changed, 2 insertions(+), 2 deletion
From: Eric Blake
Executing qemu with a terminal as stdin will temporarily alter stty
settings on that terminal (for example, disabling echo), because of
how we run both the monitor and any multiplexing with guest input.
Normally, qemu restores the original settings on exit; but if an
iotest trigg
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/191 | 153 +
tests/qemu-iotests/191.out | 827 +
tests/qemu-iotests/group | 1 +
3 files changed, 981 insertions(+)
create mode 100755 tests/qemu-iotests/191
create mode 100644 tests/qem
QMP responses to certain commands can become quite long, which doesn't
only make reading them hard, but also means that the maximum line length
in patch emails can be exceeded. Allow tests to switch to QMP pretty
printing, which results in more, but shorter lines.
We also need to make sure to keep
From: Paolo Bonzini
Signed-off-by: Paolo Bonzini
Reviewed-by: Eric Blake
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/check | 4 ++--
tests/qemu-iotests/common| 2 +-
tests/qemu-iotests/common.config | 3 ---
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/t
From: "Daniel P. Berrange"
While current encryption schemes all have a fixed sector size of
512 bytes, this is not guaranteed to be the case in future. Expose
the sector size in the APIs so the block layer can remove assumptions
about fixed 512 byte sectors.
Reviewed-by: Max Reitz
Reviewed-by:
From: Paolo Bonzini
Split "check" parts from tests part.
For the directory setup, the actual computation of directories goes
in "check", while the sanity checks go in the tests.
Signed-off-by: Paolo Bonzini
Reviewed-by: Eric Blake
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/common
From: Eric Blake
Now that all callers are using byte-based interfaces, there's no
reason for our internal hbitmap to remain with sector-based
granularity. It also simplifies our internal scaling, since we
already know that hbitmap widens requests out to granularity
boundaries.
Signed-off-by: Er
From: Thomas Huth
The condition of the for-loop makes sure that b is always smaller
than s->blocks, so the "if (b >= s->blocks)" statement is completely
superfluous here.
Buglink: https://bugs.launchpad.net/qemu/+bug/1715007
Signed-off-by: Thomas Huth
Reviewed-by: Laurent Vivier
Signed-off-by:
From: Eric Blake
Both callers already had bytes available, but were scaling to
sectors. Move the scaling to internal code. In the case of
bdrv_aligned_pwritev(), we are now passing the exact offset
rather than a rounded sector-aligned value, but that's okay
as long as dirty bitmap widens start/
From: Paolo Bonzini
This includes shell function, shell variables and command line options
(randomize.awk does not exist).
Signed-off-by: Paolo Bonzini
Reviewed-by: Eric Blake
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/check | 28 -
tests/qemu-iotests/common
From: Eric Blake
Make it easier to enable copy-on-read during iotests, by
exposing a new bool option to main and open.
Signed-off-by: Eric Blake
Reviewed-by: Jeff Cody
Reviewed-by: Kevin Wolf
Reviewed-by: John Snow
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Kevin Wolf
---
qemu-io.c | 15
From: Eric Blake
Half the callers were already scaling bytes to sectors; the other
half can eventually be simplified to use byte iteration. Both
callers were already using the result as a bool, so make that
explicit. Making the change also makes it easier for a future
dirty-bitmap patch to offl
From: Eric Blake
Thanks to recent cleanups, all callers were scaling a return value
of sectors into bytes; do the scaling internally instead.
Signed-off-by: Eric Blake
Reviewed-by: John Snow
Reviewed-by: Kevin Wolf
Reviewed-by: Fam Zheng
Signed-off-by: Kevin Wolf
---
block/dirty-bitmap.c |
This changes the commit block job to support operation in a graph where
there is more than a single active layer that references the top node.
This involves inserting the commit filter node not only on the path
between the given active node and the top node, but between the top node
and all of its
From: Eric Blake
Thanks to recent cleanups, most callers were scaling a return value
of sectors into bytes (the exception, in qcow2-bitmap, will be
converted to byte-based iteration later). Update the interface to
do the scaling internally instead.
In qcow2-bitmap, the code was specifically che
From: Paolo Bonzini
Instead of ./check failing when a binary is missing, we try each test
case now and each one fails with tons of test case diffs. Also, all the
variables were initialized by "check" prior to "common" being sourced,
and then (uselessly) checked for emptiness again in "check".
C
From: Paolo Bonzini
"check" is full of qemu-iotests--specific details. Separating it
from "common" does not make much sense anymore.
Signed-off-by: Paolo Bonzini
Reviewed-by: Eric Blake
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/check | 533 +++
From: Paolo Bonzini
It only provides functions used by the test programs.
Signed-off-by: Paolo Bonzini
Reviewed-by: Eric Blake
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/check | 6 --
tests/qemu-iotests/common.rc | 13 +
2 files changed, 5 insertions(+), 14 deletio
There is no good reason for bdrv_drop_intermediate() to know the active
layer above the subchain it is operating on - even more so, because
the assumption that there is a single active layer above it is not
generally true.
In order to prepare removal of the active parameter, use a BdrvChildRole
ca
From: Paolo Bonzini
Some functions in common.rc are never used by the tests. Move
them out of that file and into common, which is already included
only by "check".
Code that actually *is* common to "check" and tests can be placed in
common.config.
Signed-off-by: Paolo Bonzini
Reviewed-by: Eri
From: Eric Blake
Right now, the dirty-bitmap code exposes the fact that we use
a scale of sector granularity in the underlying hbitmap to anything
that wants to serialize a dirty bitmap. It's nicer to uniformly
expose bytes as our dirty-bitmap interface, matching the previous
change to bitmap si
From: Eric Blake
Now that we have adjusted the majority of the calls this function
makes to be byte-based, it is easier to read the code if it makes
passes over the image using bytes rather than sectors.
Signed-off-by: Eric Blake
Reviewed-by: John Snow
Reviewed-by: Vladimir Sementsov-Ogievskiy
From: Eric Blake
We're already reporting bytes for bdrv_dirty_bitmap_granularity();
mixing bytes and sectors in our return values is a recipe for
confusion. A later cleanup will convert dirty bitmap internals
to be entirely byte-based, but in the meantime, we should report
the bitmap size in byt
From: Eric Blake
Now that we have adjusted the majority of the calls this function
makes to be byte-based, it is easier to read the code if it makes
passes over the image using bytes rather than sectors.
Signed-off-by: Eric Blake
Reviewed-by: John Snow
Reviewed-by: Kevin Wolf
Reviewed-by: Fam
From: Eric Blake
We are gradually converting to byte-based interfaces, as they are
easier to reason about than sector-based. Change the qcow2 bitmap
helper function sectors_covered_by_bitmap_cluster(), renaming it
to bytes_covered_by_bitmap_cluster() in the process.
Signed-off-by: Eric Blake
R
From: Eric Blake
We've previously fixed several places where we failed to account
for possible errors from bdrv_nb_sectors(). Fix another one by
making bdrv_dirty_bitmap_truncate() take the new size from the
caller instead of querying itself; then adjust the sole caller
bdrv_truncate() to pass t
From: Eric Blake
We are still using an internal hbitmap that tracks a size in sectors,
with the granularity scaled down accordingly, because it lets us
use a shortcut for our iterators which are currently sector-based.
But there's no reason we can't track the dirty bitmap size in bytes,
since it
From: Eric Blake
We had several functions that no one is currently using, and which
use sector-based interfaces. I'm trying to convert towards byte-based
interfaces, so it's easier to just drop the unused functions:
bdrv_dirty_bitmap_get_meta
bdrv_dirty_bitmap_get_meta_locked
bdrv_dirty_bitmap_
From: Eric Blake
All callers to bdrv_dirty_iter_new() passed 0 for their initial
starting point, drop that parameter.
Most callers to bdrv_set_dirty_iter() were scaling a byte offset to
a sector number; the exception qcow2-bitmap will be converted later
to use byte rather than sector iteration.
From: Eric Blake
Some of the callers were already scaling bytes to sectors; others
can be easily converted to pass byte offsets, all in our shift
towards a consistent byte interface everywhere. Making the change
will also make it easier to write the hold-out callers to use byte
rather than secto
From: Eric Blake
Now that we have adjusted the majority of the calls this function
makes to be byte-based, it is easier to read the code if it makes
passes over the image using bytes rather than sectors.
iotests 165 was rather weak - on a default 64k-cluster image, where
bitmap granularity also
From: Eric Blake
This is new code, but it is easier to read if it makes passes over
the image using bytes rather than sectors (and will get easier in
the future when bdrv_get_block_status is converted to byte-based).
Signed-off-by: Eric Blake
Reviewed-by: John Snow
Reviewed-by: Kevin Wolf
Rev
From: Eric Blake
The only client of hbitmap_serialization_granularity() is dirty-bitmap's
bdrv_dirty_bitmap_serialization_align(). Keeping the two names consistent
is worthwhile, and the shorter name is more representative of what the
function returns (the required alignment to be used for start
The following changes since commit a26a98dfb9d448d7234d931ae3720feddf6f0651:
Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20171006' into
staging (2017-10-06 13:19:03 +0100)
are available in the git repository at:
git://repo.or.cz/qemu/kevin.git tags/for-upstream
From: Eric Blake
When subdividing a bitmap serialization, the code in hbitmap.c
enforces that start/count parameters are aligned (except that
count can end early at end-of-bitmap). We exposed this required
alignment through bdrv_dirty_bitmap_serialization_align(), but
forgot to actually check th
From: Eric Blake
Signed-off-by: Eric Blake
Signed-off-by: Kevin Wolf
---
block/io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/io.c b/block/io.c
index 4378ae4c7d..d633b0f851 100644
--- a/block/io.c
+++ b/block/io.c
@@ -954,7 +954,7 @@ static int coroutine_fn bdrv
From: Eric Blake
All callers of bdrv_img_create() pass in a size, or -1 to read the
size from the backing file. We then set that size as the QemuOpt
default, which means we will reuse that default rather than the
final parameter to qemu_opt_get_size() several lines later. But
it is rather confu
On Fri, Oct 06, 2017 at 09:58:33AM -0400, Doug Gale wrote:
> I tried to get tracing to work before and I have never gotten it
> working. I'll give it another try and redo the patch with tracing
> infrastructure if necessary. The printf are nice because the dev can
> just look at the terminal where
I tried to get tracing to work before and I have never gotten it
working. I'll give it another try and redo the patch with tracing
infrastructure if necessary. The printf are nice because the dev can
just look at the terminal where qemu is running. Can you view the
trace output in realtime? When th
On Fri, Oct 06, 2017 at 11:49:56AM +0200, Kevin Wolf wrote:
> Am 06.10.2017 um 01:18 hat Doug Gale geschrieben:
> > I added the tracing output in this patch to assist me in implementing
> > an NVMe driver. It helped tremendously.
> >
> > From 1d19086cdef8d492929852d582cb41dcc5026f71 Mon Sep 17 00:
On Fri, Oct 06, 2017 at 08:50:31AM -0500, Eric Blake wrote:
> On 10/05/2017 06:18 PM, Doug Gale wrote:
> > I added the tracing output in this patch to assist me in implementing
> > an NVMe driver. It helped tremendously.
> >
> >>From 1d19086cdef8d492929852d582cb41dcc5026f71 Mon Sep 17 00:00:00 200
I added the tracing output in this patch to assist me in implementing
an NVMe driver. It helped tremendously.
>From 1d19086cdef8d492929852d582cb41dcc5026f71 Mon Sep 17 00:00:00 2001
From: Doug Gale
Date: Thu, 5 Oct 2017 19:02:03 -0400
Subject: [PATCH] Add tracing output to NVMe emulation to help
On 10/05/2017 06:18 PM, Doug Gale wrote:
> I added the tracing output in this patch to assist me in implementing
> an NVMe driver. It helped tremendously.
>
>>From 1d19086cdef8d492929852d582cb41dcc5026f71 Mon Sep 17 00:00:00 2001
> From: Doug Gale
> Date: Thu, 5 Oct 2017 19:02:03 -0400
> Subject:
On Fri, Oct 06, 2017 at 02:59:55PM +0200, Max Reitz wrote:
On 2017-10-04 23:04, Manos Pitsidianakis wrote:
On Wed, Oct 04, 2017 at 08:09:24PM +0200, Max Reitz wrote:
On 2017-10-04 19:05, Manos Pitsidianakis wrote:
On Wed, Oct 04, 2017 at 02:49:27PM +0200, Max Reitz wrote:
On 2017-08-15 09:45,
On 10/06/2017 02:34 AM, Vladimir Sementsov-Ogievskiy wrote:
>> - if the chunk is NBD_REPLY_TYPE_NONE, there is no payload, and this
>> should be the final chunk, so the return to the caller can be the same
>> as for old-style (return 1 if we had no earlier error packets, or the
>> saved negative v
On 2017-10-04 23:04, Manos Pitsidianakis wrote:
> On Wed, Oct 04, 2017 at 08:09:24PM +0200, Max Reitz wrote:
>> On 2017-10-04 19:05, Manos Pitsidianakis wrote:
>>> On Wed, Oct 04, 2017 at 02:49:27PM +0200, Max Reitz wrote:
On 2017-08-15 09:45, Manos Pitsidianakis wrote:
> block-insert-node
Am 05.10.2017 um 21:02 hat Eric Blake geschrieben:
> During my quest to switch block status to be byte-based, John
> forced me to evaluate whether we have a situation during
> copy-on-read where we could exceed BDRV_REQUEST_MAX_BYTES [1].
> Sure enough, we have a number of pre-existing bugs in the
Am 06.10.2017 um 01:18 hat Doug Gale geschrieben:
> I added the tracing output in this patch to assist me in implementing
> an NVMe driver. It helped tremendously.
>
> From 1d19086cdef8d492929852d582cb41dcc5026f71 Mon Sep 17 00:00:00 2001
> From: Doug Gale
> Date: Thu, 5 Oct 2017 19:02:03 -0400
>
Am 06.10.2017 um 05:56 hat John Snow geschrieben:
> On 10/05/2017 07:38 AM, Kevin Wolf wrote:
> > Let me try to just consolidate all of the above into a single state
> > machine:
> >
> > 1. CREATED --> RUNNING
> > driver callback: .start
> > 2a. RUNNING --> READY | CANCELLED
> > v
* Markus Armbruster (arm...@redhat.com) wrote:
> Jan Dakinevich writes:
>
> > On 10/03/2017 05:02 PM, Eric Blake wrote:
> >> On 10/03/2017 07:47 AM, Jan Dakinevich wrote:
> >>> The command is intended for gathering virtio information such as status,
> >>> feature bits, negotiation status. It is c
06.10.2017 01:12, Eric Blake wrote:
On 10/05/2017 05:36 AM, Paolo Bonzini wrote:
On 05/10/2017 12:02, Vladimir Sementsov-Ogievskiy wrote:
03.10.2017 17:06, Paolo Bonzini wrote:
On 03/10/2017 15:35, Vladimir Sementsov-Ogievskiy wrote:
In the end this probably means that you have a read_chunk_h
06.10.2017 10:09, Vladimir Sementsov-Ogievskiy wrote:
06.10.2017 01:12, Eric Blake wrote:
On 10/05/2017 05:36 AM, Paolo Bonzini wrote:
On 05/10/2017 12:02, Vladimir Sementsov-Ogievskiy wrote:
03.10.2017 17:06, Paolo Bonzini wrote:
On 03/10/2017 15:35, Vladimir Sementsov-Ogievskiy wrote:
In t
06.10.2017 01:12, Eric Blake wrote:
On 10/05/2017 05:36 AM, Paolo Bonzini wrote:
On 05/10/2017 12:02, Vladimir Sementsov-Ogievskiy wrote:
03.10.2017 17:06, Paolo Bonzini wrote:
On 03/10/2017 15:35, Vladimir Sementsov-Ogievskiy wrote:
In the end this probably means that you have a read_chunk_h
80 matches
Mail list logo
