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
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.
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
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.
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
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
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
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
> 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
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
> 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
>
> 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
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
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
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
> 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
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
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 */
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
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
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
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-
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
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
-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
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.
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
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
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
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"
> >;;
>
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
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
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'
> >
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 |
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-
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
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.
, 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
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
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
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
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
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 |
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.
.
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
45 matches
Mail list logo