[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

FWIW, my VMs run with SATA and Virtio SCSI with discard=unmap and detect-zeroes=unmap (among the plethora of options from libvirtd) for maximum space savings. No problems since the fix patches went in and had no bearing on the bug occurence before that. /usr/bin/qemu-system-x86_64 -name

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

My images are still fine after some heavy use with qemu-4.1.1 and no additional patches. I consider this bug fixed for good. Thanks for all your support on this! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

All my images are still fine after some heavy use with qemu-4.1.0 and fix patches applied. Just upgraded to 4.1.1 and will report back. But it's certainly looks like this bug is fixed for good. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

I've done some security updates on my Debian, Windows 7 64 and 32 Bit VMs and quite intensively used a Windows 1903 VM today without any corruption. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

I have been dragging my feet exposing my production VMs to a patched 4.1.0 TBH. I have now taken the opportunity to upgrade from 4.0.0 to a 4.1.0 with the fix patches applied. As expected, I can not produce any image corruption with the reproducer I've been using all along. I will now use it in

Re: [PATCH v2 0/2] qcow2: Fix image corruption bug in 4.1

Hello Kevin, On Thu, Oct 24, 2019 at 04:26:56PM +0200, Kevin Wolf wrote: > Kevin Wolf (2): > coroutine: Add qemu_co_mutex_assert_locked() > qcow2: Fix corruption bug in qcow2_detect_metadata_preallocation() Tested-by: Michael Weiser with offending 69f47505e and today

Re: [PATCH 2/3] qcow2: Assert that qcow2_cache_get() callers hold s->lock

ers were found on the image. This means waste of disk space, but no harm to data. 255525/327680 = 77.98% allocated, 3.22% fragmented, 0.00% compressed clusters Image end offset: 17106403328 I was going to test with master as well but got overtaken by v2. Will move on to test v2 now. :) Series: T

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

For completeness's sake: All the changes you proposed (replacing call to qcow2_detect_metadata_preallocation() with ret = true and ret = false, moving acquiring s->lock before the call and replacing the call with a sleep) prevent corruption on my system. The latter would suggest that it's not so

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

> I think I may have had the wrong image size before because both tmpfs and > my spare LVM volume are rather limited in size. I also had a hard time to get my image to corrupt on tmpfs because it could not grow to its final size, it seems. Sometimes qemu ran into acutal ENOSPC but most of the

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

Please ignore the stuff about (!is_zero_cow(bs, m) || true) being optimized out. Of course it isn't. And corruption still occurs with that way of calling only is_zero_cow(). Dunno what I did there. It seems to be even later than I thought. The rest of my testing holds true though. -- You

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

> I tried to reproduce the problem locally, on the same commit, with the > steps you described, but I wasn't lucky. I tried keeping the image on my > home directory (XFS), on tmpfs, and finally on a newly created ext4 > filesystem on a spare LVM volume, but the image just wouldn't break even >

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

> After reading some related code, I have more questions than before, but > let's see... As more qcow2 code was merged since, I would suggest that > we debug the problem on commit 69f4750 (the bisection result) rather > than on anything newer. Okay, for all of the following I did a fresh compile

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

My qcow2 images also reside on an ext4 with features "has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file dir_nlink extra_isize metadata_csum" on a luks- encrypt(ed|ing) device mapper device backed by a partition on an NVMe SSD. The setup is rock

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

I just quickly retested with today's master (commit 69b81893bc28feb678188fbcdce52eff1609bdad) and the automated reproducer. With the attached revert patch applied the loadvm/sleep 10/savevm/quit loop ran 50 times without problem. As soon as I removed the patch, recompiled and replaced the qemu

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

Yes. As said: > qemu compiled from the commit before does not exhibit the issue, from that > commit on it does and reverting the commit off of current master makes it > disappear. In my tests the problem only occurs with that commit in the code. I used git bisect to narrow it down to that

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

> I'm seeing massive corruption of qcow2 images with qemu 4.1.0 and git master > as of 7f21573c822805a8e6be379d9bcf3ad9effef3dc after a few > savevm/quit/loadvm cycles. [...] > bisected the introduction of the problem to commit > 69f47505ee66afaa513305de0c1895a224e52c45 > (block: avoid recursive

[Bug 1846427] [NEW] 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

Public bug reported: I'm seeing massive corruption of qcow2 images with qemu 4.1.0 and git master as of 7f21573c822805a8e6be379d9bcf3ad9effef3dc after a few savevm/quit/loadvm cycles. I've narrowed it down to the following reproducer (further notes below): # qemu-img check debian.qcow2 No errors

Re: [Qemu-devel] [PATCH v2] target/arm: Fix stlxp for aarch64_be

Hi Richard, On Mon, Jan 01, 2018 at 03:06:21PM -0800, Richard Henderson wrote: > > v2: > > - make it work for MTTCG as well by catering to the 128bit expectation > Reviewed-by: Richard Henderson > > + * 128bit store but two doulbewords stored consecutively */

[Qemu-devel] [PATCH v2] target/arm: Fix stlxp for aarch64_be

to boot up in system emulation mode. Signed-off-by: Michael Weiser <michael.wei...@gmx.de> --- target/arm/helper-a64.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) v2: - make it work for MTTCG as well by catering to the 128bit expectation diff --git a/target/arm/helper-a

[Qemu-devel] [RFC PATCH] target/arm: Fix stlxp for aarch64_be

differ only in endianness handling. It might be possible to fold them into a single routine using variables and function pointers or get rid of them completely in favour of tcg_gen_-routines. Both is currently beyond my skill level, though. Signed-off-by: Michael Weiser <michael.wei...@gmx

[Qemu-devel] [PATCH v3 6/7] linux-user: Separate binfmt arm CPU families

aarch64{,_be} as well. Signed-off-by: Michael Weiser <michael.wei...@gmx.de> --- scripts/qemu-binfmt-conf.sh | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/scripts/qemu-binfmt-conf.sh b/scripts/qemu-binfmt-conf.sh index d69953525c..597efdbe50 100755 --- a/script

[Qemu-devel] [PATCH v3 5/7] linux-user: Add aarch64_be magic numbers to qemu-binfmt-conf.sh

As we now have a linux-user aarch64_be target, we can add it to the list of supported targets in qemu-binfmt-conf.sh Signed-off-by: Michael Weiser <michael.wei...@gmx.de> --- scripts/qemu-binfmt-conf.sh | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/scripts/qemu-

[Qemu-devel] [PATCH v3 2/7] linux-user: Add separate aarch64_be uname

Make big-endian aarch64 systems identify as aarch64_be as expected by big-endian userland and toolchains. Signed-off-by: Michael Weiser <michael.wei...@gmx.de> Reviewed-by: Richard Henderson <richard.hender...@linaro.org> --- linux-user/aarch64/target_syscall.h | 4 1 fil

[Qemu-devel] [PATCH v3 4/7] configure: Add aarch64_be-linux-user target

Add target aarch64_be-linux-user. This allows a qemu-aarch64_be binary to be built that will run big-endian aarch64 binaries. Signed-off-by: Michael Weiser <michael.wei...@gmx.de> Reviewed-by: Richard Henderson <richard.hender...@linaro.org> --- configure

[Qemu-devel] [PATCH v3 0/7] Add aarch64_be-linux-user target

-conf.sh - fix style problems (tab indenting) Thanks, Michael Michael Weiser (7): linux-user: Add support for big-endian aarch64 linux-user: Add separate aarch64_be uname linux-user: Fix endianess of aarch64 signal trampoline configure: Add aarch64_be-linux-user target linux-user: Add

[Qemu-devel] [PATCH v3 1/7] linux-user: Add support for big-endian aarch64

Enable big-endian mode for data accesses on aarch64 for big-endian linux user mode. Activate it for all exception levels as documented by ARM: Set the SCTLR EE bit for ELs 1 through 3. Additionally set bit E0E in EL1 to enable it in EL0 as well. Signed-off-by: Michael Weiser <michael.

[Qemu-devel] [PATCH v3 3/7] linux-user: Fix endianess of aarch64 signal trampoline

Since for aarch64 the signal trampoline is synthesized directly into the signal frame we need to make sure the instructions end up little-endian. Otherwise the wrong endianness will cause a SIGILL upon return from the signal handler on big-endian targets. Signed-off-by: Michael Weiser

[Qemu-devel] [PATCH v3 7/7] linux-user: Activate armeb handler registration

armeb is missing from the target list in qemu-binfmt-conf.sh. Add it so the handler for those binaries gets registered by the script. Signed-off-by: Michael Weiser <michael.wei...@gmx.de> --- scripts/qemu-binfmt-conf.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/s

Re: [Qemu-devel] [PATCH v2 5/5] linux-user: Add aarch64_be magic numbers to qemu-binfmt-conf.sh

Hi Laurent, On Wed, Dec 20, 2017 at 05:43:34PM +0100, Laurent Vivier wrote: > >> So it's not like on intel/AMD where we can execute a 32bit binary on a > >> 64bit kernel? > > > > An aarch64 CPU is capable of running arm (i.e. aarch32) code. And I > > think this is supported as a multilib setup

Re: [Qemu-devel] [PATCH v2 4/5] configure: Add aarch64_be-linux-user target

Hello Laurent, On Wed, Dec 20, 2017 at 03:55:03PM +0100, Laurent Vivier wrote: > > diff --git a/configure b/configure > > index 9c8aa5a98b..03d95340d8 100755 > > --- a/configure > > +++ b/configure > > @@ -657,7 +657,7 @@ case "$cpu" in > > cpu="arm" > > supported_cpu="yes" > >;; >

Re: [Qemu-devel] [PATCH v2 5/5] linux-user: Add aarch64_be magic numbers to qemu-binfmt-conf.sh

Hi Laurent, On Wed, Dec 20, 2017 at 04:56:41PM +0100, Laurent Vivier wrote: > > Based on that I suspect that qemu-binfmt-conf.sh's current assignment of > > armeb and aarch64 into the arm CPU family is over-optimistic as well. > > So I'd suggest treating all of arm, armeb, aarch64 and aarch64_be

Re: [Qemu-devel] [PATCH v2 2/5] linux-user: Add separate aarch64_be uname

Hi Peter, On Wed, Dec 20, 2017 at 03:36:29PM +, Peter Maydell wrote: > >> #define UNAME_MINIMUM_RELEASE "3.8.0" > > For aarch64_be, I think the minimum release should be 4.9.0 > > (see kernel commit cfa88c79462d "arm64: Set UTS_MACHINE in the Makefile") > Isn't the thing that defines what

Re: [Qemu-devel] [PATCH v2 5/5] linux-user: Add aarch64_be magic numbers to qemu-binfmt-conf.sh

Hi Laurent, On Wed, Dec 20, 2017 at 03:18:34PM +0100, Laurent Vivier wrote: > > +aarch64_be_magic='\x7fELF\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7' > > +aarch64_be_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff' > >

[Qemu-devel] [PATCH v2 4/5] configure: Add aarch64_be-linux-user target

Add target aarch64_be-linux-user. This allows a qemu-aarch64_be binary to be built that will run big-endian aarch64 binaries. Signed-off-by: Michael Weiser <michael.wei...@gmx.de> --- configure | 9 + default-configs/aarch64_be-linux-user.mak |

[Qemu-devel] [PATCH v2 5/5] linux-user: Add aarch64_be magic numbers to qemu-binfmt-conf.sh

As we now have a linux-user aarch64_be target, we can add it to the list of supported targets in qemu-binfmt-conf.sh Signed-off-by: Michael Weiser <michael.wei...@gmx.de> --- scripts/qemu-binfmt-conf.sh | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/scripts/qemu-

[Qemu-devel] [PATCH v2 2/5] linux-user: Add separate aarch64_be uname

Make big-endian aarch64 systems identify as aarch64_be as expected by big-endian userland and toolchains. Signed-off-by: Michael Weiser <michael.wei...@gmx.de> --- linux-user/aarch64/target_syscall.h | 4 1 file changed, 4 insertions(+) diff --git a/linux-user/aarch64/target_syscal

[Qemu-devel] [PATCH v2 1/5] linux-user: Add support for big-endian aarch64

Enable big-endian mode for data accesses on aarch64 for big-endian linux user mode. Activate it for all execution levels as documented by ARM: Set the SCTLR EE bit for ELs 1 through 3. Additionally set bit E0E in EL1 to enable it in EL0 as well. Signed-off-by: Michael Weiser <michael.

[Qemu-devel] [PATCH v2 0/5] Add aarch64_be-linux-user target

, running and compiling things (Gentoo crossdev/native). v2: - add binfmt magic to qemu-binfmt-conf.sh - fix style problems (tab indenting) Thanks, Michael Michael Weiser (5): linux-user: Add support for big-endian aarch64 linux-user: Add separate aarch64_be uname linux-user: Fix endianess

[Qemu-devel] [PATCH v2 3/5] linux-user: Fix endianess of aarch64 signal trampoline

Since for aarch64 the signal trampoline is synthesized directly into the signal frame we need to make sure the instructions end up little-endian. Otherwise the wrong endianness will cause a SIGILL upon return from the signal handler on big-endian targets. Signed-off-by: Michael Weiser

Re: [Qemu-devel] [PATCH 0/4] Add aarch64_be-linux-user target

Hello Laurent, On Tue, Dec 19, 2017 at 05:17:35PM +0100, Laurent Vivier wrote: > > below patches add support for big-endian aarch64 to linux-user. Almost > Could you also update scripts/qemu-binfmt-conf.sh for the aarch64_be magic? Done. v2 forthcoming. -- Bye, Michael

[Qemu-devel] [PATCH 2/4] linux-user: Add separate aarch64_be uname

Make big-endian aarch64 systems identify as aarch64_be as expected by big-endian userland and toolchains. Signed-off-by: Michael Weiser <michael.wei...@gmx.de> --- linux-user/aarch64/target_syscall.h | 4 1 file changed, 4 insertions(+) diff --git a/linux-user/aarch64/target_syscal

[Qemu-devel] [PATCH 3/4] linux-user: Fix endianess of aarch64 signal trampoline

Since for aarch64 the signal trampoline is synthesized directly into the signal frame we need to make sure the instructions end up little-endian. Otherwise the wrong endianness will cause a SIGILL upon return from the signal handler on big-endian targets. Signed-off-by: Michael Weiser

[Qemu-devel] [PATCH 4/4] configure: Add aarch64_be-linux-user target

Add target aarch64_be-linux-user. This allows a qemu-aarch64_be binary to be built that will run big-endian aarch64 binaries. Signed-off-by: Michael Weiser <michael.wei...@gmx.de> --- configure | 9 + default-configs/aarch64_be-linux-user.mak |

[Qemu-devel] [PATCH 1/4] linux-user: Add support for big-endian aarch64

Enable big-endian mode for data accesses on aarch64 for big-endian linux user mode. Activate it for all execution levels as documented by ARM: Set the SCTLR EE bit for ELs 1 through 3. Additionally set bit E0E in EL1 to enable it in EL0 as well. Signed-off-by: Michael Weiser <michael.

[Qemu-devel] [PATCH 0/4] Add aarch64_be-linux-user target

. Finally, configure is extended to allow building of a aarch64_be-linux-user target. With this I am able to run individual aarch64_be binaries as well as chroot into a full-blown aarch64_be userland using binfmt_misc, running and compiling things (Gentoo crossdev/native). Thanks, Michael Michael