On 07/22/2018 12:14 AM, Max Reitz wrote:
On 2018-07-19 14:47, Ari Sundholm wrote:
Hi!
On 06/28/2018 03:07 AM, Max Reitz wrote:
bdrv_refresh_filename() should invoke itself recursively on all
children, not just on file.
With that change, we can remove the manual invocations in blkverify,
quoru
On 07/20/2018 03:11 PM, Farhan Ali wrote:
I am seeing another issue pop up, in a different test. Even though it's
a different assertion, it might be related based on the call trace.
Stack trace of thread 276199:
#0 0x03ff8473e274 raise (libc.so.6)
#1 0x03ff847239a8 abort (libc.so.6
Am 18.07.2018 um 23:07 hat Michael Roth geschrieben:
> Quoting Kevin Wolf (2018-05-29 15:19:17)
> > Am 28.05.2018 um 14:03 hat Greg Kurz geschrieben:
> > > Removing a drive with drive_del while it is being used to run an I/O
> > > intensive workload can cause QEMU to crash.
> > >
> > > An AIO flus
Am 13.07.2018 um 19:37 hat John Snow geschrieben:
> This test doesn't actually care about the format anyway, it just
> supports "all formats" as a convenience. LUKS however does not use a
> simple image filename which confuses this iotest.
>
> We can simply skip the test for formats that use IMGOP
Am 13.07.2018 um 20:12 hat John Snow geschrieben:
>
>
> On 07/13/2018 03:10 AM, Kevin Wolf wrote:
> > The test case uses block devices with driver=file, which causes the test
> > to fail after commit 230ff73904 added a deprecation warning for this.
> > Fix the test case to use driver=host_device
On Mon, Jul 23, 2018 at 03:53:45PM +0200, Kevin Wolf wrote:
> Am 13.07.2018 um 20:12 hat John Snow geschrieben:
> >
> >
> > On 07/13/2018 03:10 AM, Kevin Wolf wrote:
> > > The test case uses block devices with driver=file, which causes the test
> > > to fail after commit 230ff73904 added a deprec
Am 13.07.2018 um 22:14 hat John Snow geschrieben:
>
>
> On 07/13/2018 03:41 PM, Max Reitz wrote:
> > The test directory should be filtered before the image format, otherwise
> > the test will fail if the image format is part of the test directory,
> > like so:
> >
> > [...]
> > -can't open: Coul
Am 13.07.2018 um 21:15 hat Max Reitz geschrieben:
> 223 tests persistent dirty bitmaps which are not supported in
> compat=0.10, so that option is unsupported for this test.
>
> Signed-off-by: Max Reitz
Thanks, applied to the block branch.
Kevin
Am 18.07.2018 um 17:08 hat Thomas Huth geschrieben:
> It's annoying to see this debug message every time you use vvfat.
> Disable it with the DLOG() macro by default, as it is done with the
> other debug messages in this file.
>
> Signed-off-by: Thomas Huth
Thanks, applied to the block branch.
Am 18.07.2018 um 17:28 hat Thomas Huth geschrieben:
> When using the vvfat driver with a directory that contains too many files,
> QEMU currently crashes. We are trying to print the wrong path variable here.
>
> Signed-off-by: Thomas Huth
> ---
> block/vvfat.c | 3 +--
> 1 file changed, 1 insert
On 2018-07-23 03:56, Fam Zheng wrote:
> On Sun, Jul 22, 2018 at 10:06 PM Max Reitz wrote:
>>
>> On 2018-07-22 04:37, Fam Zheng wrote:
>>> On Sun, Jul 22, 2018 at 5:08 AM Max Reitz wrote:
On 2018-07-19 05:41, Fam Zheng wrote:
> On my Fedora 28, /dev/null is locked by some other proce
On Wed, Jul 18, 2018 at 02:12:56PM -0700, Nishanth Aravamudan wrote:
> In ed6e2161 ("linux-aio: properly bubble up errors from initialzation"),
> I only added a bdrv_attach_aio_context callback for the bdrv_file
> driver. There are several other drivers that use the shared
> aio_plug callback, thou
On Fri, Jul 20, 2018 at 03:11:14PM -0400, Farhan Ali wrote:
> I am seeing another issue pop up, in a different test. Even though it's a
> different assertion, it might be related based on the call trace.
Which test case?
> Stack trace of thread 276199:
> #0 0x03ff8473e274 raise (libc.so.6)
>
On 07/23/2018 12:30 PM, Stefan Hajnoczi wrote:
On Fri, Jul 20, 2018 at 03:11:14PM -0400, Farhan Ali wrote:
I am seeing another issue pop up, in a different test. Even though it's a
different assertion, it might be related based on the call trace.
Which test case?
This test case involved o
From: Stefan Weil
Signed-off-by: Stefan Weil
Reviewed-by: John Snow
Reviewed-by: Jeff Cody
Signed-off-by: Kevin Wolf
---
block.c | 2 +-
block/backup.c | 4 ++--
block/curl.c| 2 +-
block/gluster.c | 2 +-
block/vhdx.c| 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
From: Peter Lieven
the min_sparse convert parameter can overflow (e.g. -S 1024G)
in the conversion from int64_t to int resulting in a negative
min_sparse parameter. Avoid this by limiting the valid parameters
to sane values. In fact anything exceeding the convert buffer size
is also pointless. Wh
From: Max Reitz
223 tests persistent dirty bitmaps which are not supported in
compat=0.10, so that option is unsupported for this test.
Signed-off-by: Max Reitz
Tested-by: John Snow
Reviewed-by: John Snow
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/223 | 2 ++
1 file changed, 2 inserti
From: John Snow
This test doesn't actually care about the format anyway, it just
supports "all formats" as a convenience. LUKS however does not use a
simple image filename which confuses this iotest.
We can simply skip the test for formats that use IMGOPTSSYNTAX for
their filenames without missi
The following changes since commit 55b1f14cefcb19ce6d5e28c4c83404230888aa7e:
Merge remote-tracking branch
'remotes/vivier2/tags/linux-user-for-3.0-pull-request' into staging (2018-07-23
14:03:14 +0100)
are available in the git repository at:
git://repo.or.cz/qemu/kevin.git tags/for-upstrea
From: Max Reitz
The test directory should be filtered before the image format, otherwise
the test will fail if the image format is part of the test directory,
like so:
[...]
-can't open: Could not open 'TEST_DIR/t.IMGFMT': Is a directory
+can't open: Could not open '/tmp/test-IMGFMT/t.IMGFMT': I
The test case uses block devices with driver=file, which causes the test
to fail after commit 230ff73904 added a deprecation warning for this.
Fix the test case to use driver=host_device and update the reference
output accordingly.
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/149 | 2 +
From: Thomas Huth
It's annoying to see this debug message every time you use vvfat.
Disable it with the DLOG() macro by default, as it is done with the
other debug messages in this file.
Signed-off-by: Thomas Huth
Reviewed-by: John Snow
Signed-off-by: Kevin Wolf
---
block/vvfat.c | 4 ++--
1
On 23 July 2018 at 17:45, Kevin Wolf wrote:
> The following changes since commit 55b1f14cefcb19ce6d5e28c4c83404230888aa7e:
>
> Merge remote-tracking branch
> 'remotes/vivier2/tags/linux-user-for-3.0-pull-request' into staging
> (2018-07-23 14:03:14 +0100)
>
> are available in the git repositor
This patch aims to bring the following behavior:
1. Bitmaps are not loaded on open if BDRV_O_INACTIVE is set, which occurs
for incoming migration cases. We will load these persistent bitmaps
on invalidate instead.
2. Regardless of the migration circumstances, persistent bitmaps are
alway
Presently, we emulate a block migration by just using a different
target file. Update the test to actually request a block migration.
Signed-off-by: John Snow
---
tests/qemu-iotests/169 | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/qemu-iotests/169 b/tests/qemu-iotests/169
index d
From: Vladimir Sementsov-Ogievskiy
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Message-id: 20180626135035.133432-2-vsement...@virtuozzo.com
Signed-off-by: John Snow
---
tests/qemu-iotests/169 | 1 -
1 file changed, 1 deletion(-)
diff --git a/tests/qemu-iotests/169 b/te
From: Vladimir Sementsov-Ogievskiy
Signed-off-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: John Snow
---
block/qcow2.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index 6162ed8be2..7444133ccd 100644
--- a/block/qcow2.c
+++ b/block/
From: Vladimir Sementsov-Ogievskiy
This variable doesn't work as it should, because it is actually cleared
in qcow2_co_invalidate_cache() by memset(). Drop it, as the following
patch will introduce new behavior.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: John Snow
Signed-off-by:
From: Vladimir Sementsov-Ogievskiy
Before previous patch, iotest 169 was actually broken for the case
test_persistent__not_migbitmap__offline_shared, while formally
passing.
After migration log of vm_b had message:
qemu-system-x86_64: Could not reopen qcow2 layer: Bitmap already
exists:
This is an updated version of Vladimir's proposal for fixing the
handling around migration and persistent dirty bitmaps.
Patches 1, 4, 6, and 7 update the testing for this feature.
Patch 2 touches up an error message.
Patch 3 removes dead code.
Patch 5 contains the real fix.
v2:
- Add a new patc
From: Vladimir Sementsov-Ogievskiy
Test that we can resume source vm after [failed] migration, and bitmaps
are ok.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: John Snow
---
tests/qemu-iotests/169 | 59 +-
tests/qemu-iotests/169.ou
On Mon, Jul 23, 2018 at 10:37 PM Max Reitz wrote:
>
> On 2018-07-23 03:56, Fam Zheng wrote:
> > On Sun, Jul 22, 2018 at 10:06 PM Max Reitz wrote:
> >>
> >> On 2018-07-22 04:37, Fam Zheng wrote:
> >>> On Sun, Jul 22, 2018 at 5:08 AM Max Reitz wrote:
>
> On 2018-07-19 05:41, Fam Zheng wr
32 matches
Mail list logo
