Re: [PATCH v2 for-5.1] acpi-pm-tmr: allow any small-size reads
On Tue, 14 Jul 2020 07:10:14 -0400, Michael S. Tsirkin wrote: On Tue, Jul 14, 2020 at 01:51:13PM +0300, Michael Tokarev wrote: As found in LP#1886318, MacOS Catalina performs 2-byte reads on the acpi timer address space while the spec says it should be 4-byte. Allow any small reads. Reported-By: Simon John Signed-off-by: Michael Tokarev Simon's explanation about the history is good to have here, and I guess Fixes tags (both what you found and what Simon found) can't hurt either. I would CC stable too. Simon do you have the time to iterate on this patch or would you rather have Michael do it? Sorry, I seem to not be getting all of these emails but trying to watch the list archive. I just tested Michael's v2 patch and it works fine: static const MemoryRegionOps acpi_pm_tmr_ops = { .read = acpi_pm_tmr_read, .write = acpi_pm_tmr_write, .impl.min_access_size = 4, .valid.min_access_size = 1, .valid.max_access_size = 4, .endianness = DEVICE_LITTLE_ENDIAN, }; I'm happy for Michael to proceed with the patch, he's mentioned me and linked to the launchpad bug where the history is. Regards. -- Simon John
[Bug 1886318] Re: Qemu after v5.0.0 breaks macos guests
Hi Mark, Yes I am getting the emails from qemu-devel thanks (seems pretty slow though - the website is faster) I replied to a couple but its over my head mostly now! I didn't notice Michael had done a v2 patch for 5.1, that's fine with me. I wonder if we can get the debian 5.0 package updated with a patch, or if we have to wait for 5.1 to be packaged with the fix already included from upstream? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1886318 Title: Qemu after v5.0.0 breaks macos guests Status in QEMU: New Bug description: The Debian Sid 5.0-6 qemu-kvm package can no longer get further than the Clover bootloader whereas 5.0-6 and earlier worked fine. So I built qemu master from github and it has the same problem, whereas git tag v5.0.0 (or 4.2.1) does not, so something between v5.0.0 release and the last few days has caused the problem. Here's my qemu script, pretty standard macOS-Simple-KVM setup on a Xeon host: qemu-system-x86_64 \ -enable-kvm \ -m 4G \ -machine q35,accel=kvm \ -smp 4,sockets=1,cores=2,threads=2 \ -cpu Penryn,vendor=GenuineIntel,kvm=on,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc \ -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \ -smbios type=2 \ -drive if=pflash,format=raw,readonly,file="/tmp/OVMF_CODE.fd" \ -drive if=pflash,format=raw,file="/tmp/macos_catalina_VARS.fd" \ -vga qxl \ -device ich9-ahci,id=sata \ -drive id=ESP,if=none,format=raw,file=/tmp/ESP.img \ -device ide-hd,bus=sata.2,drive=ESP \ -drive id=InstallMedia,format=raw,if=none,file=/tmp/BaseSystem.img \ -device ide-hd,bus=sata.3,drive=InstallMedia \ -drive id=SystemDisk,if=none,format=raw,file=/tmp/macos_catalina.img \ -device ide-hd,bus=sata.4,drive=SystemDisk \ -usb -device usb-kbd -device usb-mouse Perhaps something has changed in Penryn support recently, as that's required for macos? See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247 Also on a related note, kernel 5.6/5.7 (on Debian) hard crashes the host when I try GPU passthrough on macos, whereas Ubuntu20/Win10 work fine - as does 5.5 kernel. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961676 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1886318/+subscriptions
Re: [PATCH] Allow acpi-tmr size=2
On Mon, 13 Jul 2020 08:17:41 -0400, Michael S. Tsirkin wrote: Sounds good. And how about also adding: .impl.min_access_size = 4, ? Yes, this works too - what does that do? static const MemoryRegionOps acpi_pm_tmr_ops = { .read = acpi_pm_tmr_read, .write = acpi_pm_tmr_write, .valid.min_access_size = 2, .valid.max_access_size = 4, .impl.min_access_size = 4, .impl.max_access_size = 4, .endianness = DEVICE_LITTLE_ENDIAN, }; Regards. -- Simon John
Re: [PATCH] Allow acpi-tmr size=2
I don't profess to understand most of this, I am just a user who found something didn't work and tracked down the cause with help from the people on the bugtracker. the min=1 and max=4 was chosen as it seems to be set that way in most other places in the source, and 2 fits in that range. so as macos seems to require 2 bytes but spec says 4 (32 bits) would it be better to set min=2 max=4, given that the original revert seems to be a security fix? this works equally well: static const MemoryRegionOps acpi_pm_tmr_ops = { .read = acpi_pm_tmr_read, .write = acpi_pm_tmr_write, .valid.min_access_size = 2, .valid.max_access_size = 4, .endianness = DEVICE_LITTLE_ENDIAN, }; regards. On 13/07/2020 12:14, Michael S. Tsirkin wrote: On Mon, Jul 13, 2020 at 10:20:12AM +0300, Michael Tokarev wrote: 12.07.2020 15:00, Simon John wrote: macos guests no longer boot after commit 5d971f9e672507210e77d020d89e0e89165c8fc9 acpi-tmr needs 2 byte memory accesses, so breaks as that commit only allows 4 bytes. Fixes: 5d971f9e672507210e7 (memory: Revert "memory: accept mismatching sizes in memory_region_access_valid") Buglink: https://bugs.launchpad.net/qemu/+bug/1886318 Actually this fixes 77d58b1e47c8d1c661f98f12b47ab519d3561488 Author: Gerd Hoffmann Date: Thu Nov 22 12:12:30 2012 +0100 Subject: apci: switch timer to memory api Signed-off-by: Gerd Hoffmann because this is the commit which put min_access_size = 4 in there (5d971f9e672507210e7 is just a messenger, actual error were here earlier but it went unnoticed). While min_access_size=4 was most likely an error, I wonder why we use 1 now, while the subject says it needs 2? What real min size is here for ACPI PM timer? /mjt Well the ACPI spec 1.0b says 4.7.3.3 Power Management Timer (PM_TMR) ... This register is accessed as 32 bits. and this text is still there in 6.2. So it's probably worth it to cite this in the commit log and explain it's a spec violation. I think it's better to be restrictive and only allow the minimal variation from spec - in this case I guess this means 2 byte reads. In any case pls do include an explanation for why you picked one over the other. Signed-off-by: Simon John --- Â hw/acpi/core.c | 2 +- Â 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/acpi/core.c b/hw/acpi/core.c index f6d9ec4f13..05ff29b9d7 100644 --- a/hw/acpi/core.c +++ b/hw/acpi/core.c @@ -527,7 +527,7 @@ static void acpi_pm_tmr_write(void *opaque, hwaddr addr, uint64_t val, Â static const MemoryRegionOps acpi_pm_tmr_ops = { Â Â Â Â .read = acpi_pm_tmr_read, Â Â Â Â .write = acpi_pm_tmr_write, -Â Â Â .valid.min_access_size = 4, +Â Â Â .valid.min_access_size = 1, Â Â Â Â .valid.max_access_size = 4, Â Â Â Â .endianness = DEVICE_LITTLE_ENDIAN, Â }; -- Simon John
[PATCH] Allow acpi-tmr size=2
macos guests no longer boot after commit 5d971f9e672507210e77d020d89e0e89165c8fc9 acpi-tmr needs 2 byte memory accesses, so breaks as that commit only allows 4 bytes. Fixes: 5d971f9e672507210e7 (memory: Revert "memory: accept mismatching sizes in memory_region_access_valid") Buglink: https://bugs.launchpad.net/qemu/+bug/1886318 Signed-off-by: Simon John --- hw/acpi/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/acpi/core.c b/hw/acpi/core.c index f6d9ec4f13..05ff29b9d7 100644 --- a/hw/acpi/core.c +++ b/hw/acpi/core.c @@ -527,7 +527,7 @@ static void acpi_pm_tmr_write(void *opaque, hwaddr addr, uint64_t val, static const MemoryRegionOps acpi_pm_tmr_ops = { .read = acpi_pm_tmr_read, .write = acpi_pm_tmr_write, -.valid.min_access_size = 4, +.valid.min_access_size = 1, .valid.max_access_size = 4, .endianness = DEVICE_LITTLE_ENDIAN, }; -- 2.27.0
[Bug 1886318] Re: Qemu after v5.0.0 breaks macos guests
urgh, that was complicated, think i got it right! need to look for "[PATCH] Allow acpi-tmr size=2" to show up in qemu- devel -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1886318 Title: Qemu after v5.0.0 breaks macos guests Status in QEMU: New Bug description: The Debian Sid 5.0-6 qemu-kvm package can no longer get further than the Clover bootloader whereas 5.0-6 and earlier worked fine. So I built qemu master from github and it has the same problem, whereas git tag v5.0.0 (or 4.2.1) does not, so something between v5.0.0 release and the last few days has caused the problem. Here's my qemu script, pretty standard macOS-Simple-KVM setup on a Xeon host: qemu-system-x86_64 \ -enable-kvm \ -m 4G \ -machine q35,accel=kvm \ -smp 4,sockets=1,cores=2,threads=2 \ -cpu Penryn,vendor=GenuineIntel,kvm=on,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc \ -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \ -smbios type=2 \ -drive if=pflash,format=raw,readonly,file="/tmp/OVMF_CODE.fd" \ -drive if=pflash,format=raw,file="/tmp/macos_catalina_VARS.fd" \ -vga qxl \ -device ich9-ahci,id=sata \ -drive id=ESP,if=none,format=raw,file=/tmp/ESP.img \ -device ide-hd,bus=sata.2,drive=ESP \ -drive id=InstallMedia,format=raw,if=none,file=/tmp/BaseSystem.img \ -device ide-hd,bus=sata.3,drive=InstallMedia \ -drive id=SystemDisk,if=none,format=raw,file=/tmp/macos_catalina.img \ -device ide-hd,bus=sata.4,drive=SystemDisk \ -usb -device usb-kbd -device usb-mouse Perhaps something has changed in Penryn support recently, as that's required for macos? See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247 Also on a related note, kernel 5.6/5.7 (on Debian) hard crashes the host when I try GPU passthrough on macos, whereas Ubuntu20/Win10 work fine - as does 5.5 kernel. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961676 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1886318/+subscriptions
[Bug 1886318] Re: Qemu after v5.0.0 breaks macos guests
on a hunch, i applied this, and now macos boots (as 2 from acpi-tmr fits in the 1-4 range): diff --git a/hw/acpi/core.c b/hw/acpi/core.c index f6d9ec4f13..05ff29b9d7 100644 --- a/hw/acpi/core.c +++ b/hw/acpi/core.c @@ -527,7 +527,7 @@ static void acpi_pm_tmr_write(void *opaque, hwaddr addr, uint64_t val, static const MemoryRegionOps acpi_pm_tmr_ops = { .read = acpi_pm_tmr_read, .write = acpi_pm_tmr_write, -.valid.min_access_size = 4, +.valid.min_access_size = 1, .valid.max_access_size = 4, .endianness = DEVICE_LITTLE_ENDIAN, }; -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1886318 Title: Qemu after v5.0.0 breaks macos guests Status in QEMU: New Bug description: The Debian Sid 5.0-6 qemu-kvm package can no longer get further than the Clover bootloader whereas 5.0-6 and earlier worked fine. So I built qemu master from github and it has the same problem, whereas git tag v5.0.0 (or 4.2.1) does not, so something between v5.0.0 release and the last few days has caused the problem. Here's my qemu script, pretty standard macOS-Simple-KVM setup on a Xeon host: qemu-system-x86_64 \ -enable-kvm \ -m 4G \ -machine q35,accel=kvm \ -smp 4,sockets=1,cores=2,threads=2 \ -cpu Penryn,vendor=GenuineIntel,kvm=on,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc \ -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \ -smbios type=2 \ -drive if=pflash,format=raw,readonly,file="/tmp/OVMF_CODE.fd" \ -drive if=pflash,format=raw,file="/tmp/macos_catalina_VARS.fd" \ -vga qxl \ -device ich9-ahci,id=sata \ -drive id=ESP,if=none,format=raw,file=/tmp/ESP.img \ -device ide-hd,bus=sata.2,drive=ESP \ -drive id=InstallMedia,format=raw,if=none,file=/tmp/BaseSystem.img \ -device ide-hd,bus=sata.3,drive=InstallMedia \ -drive id=SystemDisk,if=none,format=raw,file=/tmp/macos_catalina.img \ -device ide-hd,bus=sata.4,drive=SystemDisk \ -usb -device usb-kbd -device usb-mouse Perhaps something has changed in Penryn support recently, as that's required for macos? See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247 Also on a related note, kernel 5.6/5.7 (on Debian) hard crashes the host when I try GPU passthrough on macos, whereas Ubuntu20/Win10 work fine - as does 5.5 kernel. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961676 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1886318/+subscriptions
[Bug 1886318] Re: Qemu after v5.0.0 breaks macos guests
all i get on stderr with my patch is: invalid accepts: (null) addr fe03601c size: 4 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1886318 Title: Qemu after v5.0.0 breaks macos guests Status in QEMU: New Bug description: The Debian Sid 5.0-6 qemu-kvm package can no longer get further than the Clover bootloader whereas 5.0-6 and earlier worked fine. So I built qemu master from github and it has the same problem, whereas git tag v5.0.0 (or 4.2.1) does not, so something between v5.0.0 release and the last few days has caused the problem. Here's my qemu script, pretty standard macOS-Simple-KVM setup on a Xeon host: qemu-system-x86_64 \ -enable-kvm \ -m 4G \ -machine q35,accel=kvm \ -smp 4,sockets=1,cores=2,threads=2 \ -cpu Penryn,vendor=GenuineIntel,kvm=on,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc \ -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \ -smbios type=2 \ -drive if=pflash,format=raw,readonly,file="/tmp/OVMF_CODE.fd" \ -drive if=pflash,format=raw,file="/tmp/macos_catalina_VARS.fd" \ -vga qxl \ -device ich9-ahci,id=sata \ -drive id=ESP,if=none,format=raw,file=/tmp/ESP.img \ -device ide-hd,bus=sata.2,drive=ESP \ -drive id=InstallMedia,format=raw,if=none,file=/tmp/BaseSystem.img \ -device ide-hd,bus=sata.3,drive=InstallMedia \ -drive id=SystemDisk,if=none,format=raw,file=/tmp/macos_catalina.img \ -device ide-hd,bus=sata.4,drive=SystemDisk \ -usb -device usb-kbd -device usb-mouse Perhaps something has changed in Penryn support recently, as that's required for macos? See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247 Also on a related note, kernel 5.6/5.7 (on Debian) hard crashes the host when I try GPU passthrough on macos, whereas Ubuntu20/Win10 work fine - as does 5.5 kernel. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961676 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1886318/+subscriptions
[Bug 1886318] Re: Qemu after v5.0.0 breaks macos guests
i get this over and over (and only this): invalid size: acpi-tmr addr 0 size: 2 which seems to reside in hw/acpi/core.c -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1886318 Title: Qemu after v5.0.0 breaks macos guests Status in QEMU: New Bug description: The Debian Sid 5.0-6 qemu-kvm package can no longer get further than the Clover bootloader whereas 5.0-6 and earlier worked fine. So I built qemu master from github and it has the same problem, whereas git tag v5.0.0 (or 4.2.1) does not, so something between v5.0.0 release and the last few days has caused the problem. Here's my qemu script, pretty standard macOS-Simple-KVM setup on a Xeon host: qemu-system-x86_64 \ -enable-kvm \ -m 4G \ -machine q35,accel=kvm \ -smp 4,sockets=1,cores=2,threads=2 \ -cpu Penryn,vendor=GenuineIntel,kvm=on,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc \ -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \ -smbios type=2 \ -drive if=pflash,format=raw,readonly,file="/tmp/OVMF_CODE.fd" \ -drive if=pflash,format=raw,file="/tmp/macos_catalina_VARS.fd" \ -vga qxl \ -device ich9-ahci,id=sata \ -drive id=ESP,if=none,format=raw,file=/tmp/ESP.img \ -device ide-hd,bus=sata.2,drive=ESP \ -drive id=InstallMedia,format=raw,if=none,file=/tmp/BaseSystem.img \ -device ide-hd,bus=sata.3,drive=InstallMedia \ -drive id=SystemDisk,if=none,format=raw,file=/tmp/macos_catalina.img \ -device ide-hd,bus=sata.4,drive=SystemDisk \ -usb -device usb-kbd -device usb-mouse Perhaps something has changed in Penryn support recently, as that's required for macos? See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247 Also on a related note, kernel 5.6/5.7 (on Debian) hard crashes the host when I try GPU passthrough on macos, whereas Ubuntu20/Win10 work fine - as does 5.5 kernel. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961676 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1886318/+subscriptions
[Bug 1886318] Re: Qemu after v5.0.0 breaks macos guests
No that doesn't make any difference either, nor does combining the two patches :-( -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1886318 Title: Qemu after v5.0.0 breaks macos guests Status in QEMU: New Bug description: The Debian Sid 5.0-6 qemu-kvm package can no longer get further than the Clover bootloader whereas 5.0-6 and earlier worked fine. So I built qemu master from github and it has the same problem, whereas git tag v5.0.0 (or 4.2.1) does not, so something between v5.0.0 release and the last few days has caused the problem. Here's my qemu script, pretty standard macOS-Simple-KVM setup on a Xeon host: qemu-system-x86_64 \ -enable-kvm \ -m 4G \ -machine q35,accel=kvm \ -smp 4,sockets=1,cores=2,threads=2 \ -cpu Penryn,vendor=GenuineIntel,kvm=on,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc \ -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \ -smbios type=2 \ -drive if=pflash,format=raw,readonly,file="/tmp/OVMF_CODE.fd" \ -drive if=pflash,format=raw,file="/tmp/macos_catalina_VARS.fd" \ -vga qxl \ -device ich9-ahci,id=sata \ -drive id=ESP,if=none,format=raw,file=/tmp/ESP.img \ -device ide-hd,bus=sata.2,drive=ESP \ -drive id=InstallMedia,format=raw,if=none,file=/tmp/BaseSystem.img \ -device ide-hd,bus=sata.3,drive=InstallMedia \ -drive id=SystemDisk,if=none,format=raw,file=/tmp/macos_catalina.img \ -device ide-hd,bus=sata.4,drive=SystemDisk \ -usb -device usb-kbd -device usb-mouse Perhaps something has changed in Penryn support recently, as that's required for macos? See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247 Also on a related note, kernel 5.6/5.7 (on Debian) hard crashes the host when I try GPU passthrough on macos, whereas Ubuntu20/Win10 work fine - as does 5.5 kernel. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961676 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1886318/+subscriptions
[Bug 1886318] Re: Qemu after v5.0.0 breaks macos guests
Hi Mark, no that doesn't work sorry, same error. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1886318 Title: Qemu after v5.0.0 breaks macos guests Status in QEMU: New Bug description: The Debian Sid 5.0-6 qemu-kvm package can no longer get further than the Clover bootloader whereas 5.0-6 and earlier worked fine. So I built qemu master from github and it has the same problem, whereas git tag v5.0.0 (or 4.2.1) does not, so something between v5.0.0 release and the last few days has caused the problem. Here's my qemu script, pretty standard macOS-Simple-KVM setup on a Xeon host: qemu-system-x86_64 \ -enable-kvm \ -m 4G \ -machine q35,accel=kvm \ -smp 4,sockets=1,cores=2,threads=2 \ -cpu Penryn,vendor=GenuineIntel,kvm=on,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc \ -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \ -smbios type=2 \ -drive if=pflash,format=raw,readonly,file="/tmp/OVMF_CODE.fd" \ -drive if=pflash,format=raw,file="/tmp/macos_catalina_VARS.fd" \ -vga qxl \ -device ich9-ahci,id=sata \ -drive id=ESP,if=none,format=raw,file=/tmp/ESP.img \ -device ide-hd,bus=sata.2,drive=ESP \ -drive id=InstallMedia,format=raw,if=none,file=/tmp/BaseSystem.img \ -device ide-hd,bus=sata.3,drive=InstallMedia \ -drive id=SystemDisk,if=none,format=raw,file=/tmp/macos_catalina.img \ -device ide-hd,bus=sata.4,drive=SystemDisk \ -usb -device usb-kbd -device usb-mouse Perhaps something has changed in Penryn support recently, as that's required for macos? See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247 Also on a related note, kernel 5.6/5.7 (on Debian) hard crashes the host when I try GPU passthrough on macos, whereas Ubuntu20/Win10 work fine - as does 5.5 kernel. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961676 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1886318/+subscriptions
[Bug 1886318] Re: Qemu after v5.0.0 breaks macos guests
yup, building debian 5.0-6 package minus that single patch gives me working macos catalina again. now just got to figure out why any kernel newer than 5.5 crashes the host when using pci passthrough - i don't fancy bisecting a whole kernel! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1886318 Title: Qemu after v5.0.0 breaks macos guests Status in QEMU: New Bug description: The Debian Sid 5.0-6 qemu-kvm package can no longer get further than the Clover bootloader whereas 5.0-6 and earlier worked fine. So I built qemu master from github and it has the same problem, whereas git tag v5.0.0 (or 4.2.1) does not, so something between v5.0.0 release and the last few days has caused the problem. Here's my qemu script, pretty standard macOS-Simple-KVM setup on a Xeon host: qemu-system-x86_64 \ -enable-kvm \ -m 4G \ -machine q35,accel=kvm \ -smp 4,sockets=1,cores=2,threads=2 \ -cpu Penryn,vendor=GenuineIntel,kvm=on,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc \ -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \ -smbios type=2 \ -drive if=pflash,format=raw,readonly,file="/tmp/OVMF_CODE.fd" \ -drive if=pflash,format=raw,file="/tmp/macos_catalina_VARS.fd" \ -vga qxl \ -device ich9-ahci,id=sata \ -drive id=ESP,if=none,format=raw,file=/tmp/ESP.img \ -device ide-hd,bus=sata.2,drive=ESP \ -drive id=InstallMedia,format=raw,if=none,file=/tmp/BaseSystem.img \ -device ide-hd,bus=sata.3,drive=InstallMedia \ -drive id=SystemDisk,if=none,format=raw,file=/tmp/macos_catalina.img \ -device ide-hd,bus=sata.4,drive=SystemDisk \ -usb -device usb-kbd -device usb-mouse Perhaps something has changed in Penryn support recently, as that's required for macos? See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247 Also on a related note, kernel 5.6/5.7 (on Debian) hard crashes the host when I try GPU passthrough on macos, whereas Ubuntu20/Win10 work fine - as does 5.5 kernel. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961676 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1886318/+subscriptions
[Bug 1886318] Re: Qemu after v5.0.0 breaks macos guests
the debian patch is: revert-memory-accept-mismatching-sizes-in-memory_region_access_valid- CVE-2020-13754.patch i'm currently building a deb package without it. mailserver has a geoip block and doesn't use ipv6, synapticconsulting at gmail dot com should work. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1886318 Title: Qemu after v5.0.0 breaks macos guests Status in QEMU: New Bug description: The Debian Sid 5.0-6 qemu-kvm package can no longer get further than the Clover bootloader whereas 5.0-6 and earlier worked fine. So I built qemu master from github and it has the same problem, whereas git tag v5.0.0 (or 4.2.1) does not, so something between v5.0.0 release and the last few days has caused the problem. Here's my qemu script, pretty standard macOS-Simple-KVM setup on a Xeon host: qemu-system-x86_64 \ -enable-kvm \ -m 4G \ -machine q35,accel=kvm \ -smp 4,sockets=1,cores=2,threads=2 \ -cpu Penryn,vendor=GenuineIntel,kvm=on,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc \ -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \ -smbios type=2 \ -drive if=pflash,format=raw,readonly,file="/tmp/OVMF_CODE.fd" \ -drive if=pflash,format=raw,file="/tmp/macos_catalina_VARS.fd" \ -vga qxl \ -device ich9-ahci,id=sata \ -drive id=ESP,if=none,format=raw,file=/tmp/ESP.img \ -device ide-hd,bus=sata.2,drive=ESP \ -drive id=InstallMedia,format=raw,if=none,file=/tmp/BaseSystem.img \ -device ide-hd,bus=sata.3,drive=InstallMedia \ -drive id=SystemDisk,if=none,format=raw,file=/tmp/macos_catalina.img \ -device ide-hd,bus=sata.4,drive=SystemDisk \ -usb -device usb-kbd -device usb-mouse Perhaps something has changed in Penryn support recently, as that's required for macos? See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247 Also on a related note, kernel 5.6/5.7 (on Debian) hard crashes the host when I try GPU passthrough on macos, whereas Ubuntu20/Win10 work fine - as does 5.5 kernel. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961676 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1886318/+subscriptions
[Bug 1886318] Re: Qemu after v5.0.0 breaks macos guests
Woohoo! Simply reverting that one commit 5d971f9e672507210e77d020d89e0e89165c8fc9 from today's master gets me running again. Not sure where that leaves us though? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1886318 Title: Qemu after v5.0.0 breaks macos guests Status in QEMU: New Bug description: The Debian Sid 5.0-6 qemu-kvm package can no longer get further than the Clover bootloader whereas 5.0-6 and earlier worked fine. So I built qemu master from github and it has the same problem, whereas git tag v5.0.0 (or 4.2.1) does not, so something between v5.0.0 release and the last few days has caused the problem. Here's my qemu script, pretty standard macOS-Simple-KVM setup on a Xeon host: qemu-system-x86_64 \ -enable-kvm \ -m 4G \ -machine q35,accel=kvm \ -smp 4,sockets=1,cores=2,threads=2 \ -cpu Penryn,vendor=GenuineIntel,kvm=on,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc \ -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \ -smbios type=2 \ -drive if=pflash,format=raw,readonly,file="/tmp/OVMF_CODE.fd" \ -drive if=pflash,format=raw,file="/tmp/macos_catalina_VARS.fd" \ -vga qxl \ -device ich9-ahci,id=sata \ -drive id=ESP,if=none,format=raw,file=/tmp/ESP.img \ -device ide-hd,bus=sata.2,drive=ESP \ -drive id=InstallMedia,format=raw,if=none,file=/tmp/BaseSystem.img \ -device ide-hd,bus=sata.3,drive=InstallMedia \ -drive id=SystemDisk,if=none,format=raw,file=/tmp/macos_catalina.img \ -device ide-hd,bus=sata.4,drive=SystemDisk \ -usb -device usb-kbd -device usb-mouse Perhaps something has changed in Penryn support recently, as that's required for macos? See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247 Also on a related note, kernel 5.6/5.7 (on Debian) hard crashes the host when I try GPU passthrough on macos, whereas Ubuntu20/Win10 work fine - as does 5.5 kernel. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961676 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1886318/+subscriptions
[Bug 1886318] Re: Qemu after v5.0.0 breaks macos guests
Thanks Mark, what an interesting exercise that was - and sorry, didn't know 5.1 was due. So the git bisect revealed this: $ git bisect good 5d971f9e672507210e77d020d89e0e89165c8fc9 is the first bad commit commit 5d971f9e672507210e77d020d89e0e89165c8fc9 Author: Michael S. Tsirkin Date: Wed Jun 10 09:47:49 2020 -0400 memory: Revert "memory: accept mismatching sizes in memory_region_access_valid" Memory API documentation documents valid .min_access_size and .max_access_size fields and explains that any access outside these boundaries is blocked. This is what devices seem to assume. However this is not what the implementation does: it simply ignores the boundaries unless there's an "accepts" callback. Naturally, this breaks a bunch of devices. Revert to the documented behaviour. Devices that want to allow any access can just drop the valid field, or add the impl field to have accesses converted to appropriate length. Cc: qemu-sta...@nongnu.org Reviewed-by: Richard Henderson Fixes: CVE-2020-13754 Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1842363 Fixes: a014ed07bd5a ("memory: accept mismatching sizes in memory_region_access_valid") Signed-off-by: Michael S. Tsirkin Message-Id: <20200610134731.1514409-1-...@redhat.com> Signed-off-by: Paolo Bonzini memory.c | 29 + 1 file changed, 9 insertions(+), 20 deletions(-) ** Bug watch added: Red Hat Bugzilla #1842363 https://bugzilla.redhat.com/show_bug.cgi?id=1842363 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-13754 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1886318 Title: Qemu after v5.0.0 breaks macos guests Status in QEMU: New Bug description: The Debian Sid 5.0-6 qemu-kvm package can no longer get further than the Clover bootloader whereas 5.0-6 and earlier worked fine. So I built qemu master from github and it has the same problem, whereas git tag v5.0.0 (or 4.2.1) does not, so something between v5.0.0 release and the last few days has caused the problem. Here's my qemu script, pretty standard macOS-Simple-KVM setup on a Xeon host: qemu-system-x86_64 \ -enable-kvm \ -m 4G \ -machine q35,accel=kvm \ -smp 4,sockets=1,cores=2,threads=2 \ -cpu Penryn,vendor=GenuineIntel,kvm=on,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc \ -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \ -smbios type=2 \ -drive if=pflash,format=raw,readonly,file="/tmp/OVMF_CODE.fd" \ -drive if=pflash,format=raw,file="/tmp/macos_catalina_VARS.fd" \ -vga qxl \ -device ich9-ahci,id=sata \ -drive id=ESP,if=none,format=raw,file=/tmp/ESP.img \ -device ide-hd,bus=sata.2,drive=ESP \ -drive id=InstallMedia,format=raw,if=none,file=/tmp/BaseSystem.img \ -device ide-hd,bus=sata.3,drive=InstallMedia \ -drive id=SystemDisk,if=none,format=raw,file=/tmp/macos_catalina.img \ -device ide-hd,bus=sata.4,drive=SystemDisk \ -usb -device usb-kbd -device usb-mouse Perhaps something has changed in Penryn support recently, as that's required for macos? See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247 Also on a related note, kernel 5.6/5.7 (on Debian) hard crashes the host when I try GPU passthrough on macos, whereas Ubuntu20/Win10 work fine - as does 5.5 kernel. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961676 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1886318/+subscriptions
[Bug 1886318] Re: Qemu after v5.0.0 breaks macos guests
qemu console screenshot, this is as far as it gets after clover: https://i.imgur.com/HWY96Kq.png same result with or without usb/pci passthrough, qxl/vnc, git master HEAD or debian 5.0-6 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1886318 Title: Qemu after v5.0.0 breaks macos guests Status in QEMU: New Bug description: The Debian Sid 5.0-6 qemu-kvm package can no longer get further than the Clover bootloader whereas 5.0-6 and earlier worked fine. So I built qemu master from github and it has the same problem, whereas git tag v5.0.0 (or 4.2.1) does not, so something between v5.0.0 release and the last few days has caused the problem. Here's my qemu script, pretty standard macOS-Simple-KVM setup on a Xeon host: qemu-system-x86_64 \ -enable-kvm \ -m 4G \ -machine q35,accel=kvm \ -smp 4,sockets=1,cores=2,threads=2 \ -cpu Penryn,vendor=GenuineIntel,kvm=on,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc \ -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \ -smbios type=2 \ -drive if=pflash,format=raw,readonly,file="/tmp/OVMF_CODE.fd" \ -drive if=pflash,format=raw,file="/tmp/macos_catalina_VARS.fd" \ -vga qxl \ -device ich9-ahci,id=sata \ -drive id=ESP,if=none,format=raw,file=/tmp/ESP.img \ -device ide-hd,bus=sata.2,drive=ESP \ -drive id=InstallMedia,format=raw,if=none,file=/tmp/BaseSystem.img \ -device ide-hd,bus=sata.3,drive=InstallMedia \ -drive id=SystemDisk,if=none,format=raw,file=/tmp/macos_catalina.img \ -device ide-hd,bus=sata.4,drive=SystemDisk \ -usb -device usb-kbd -device usb-mouse Perhaps something has changed in Penryn support recently, as that's required for macos? See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247 Also on a related note, kernel 5.6/5.7 (on Debian) hard crashes the host when I try GPU passthrough on macos, whereas Ubuntu20/Win10 work fine - as does 5.5 kernel. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961676 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1886318/+subscriptions
[Bug 1886318] Re: Qemu after v5.0.0 breaks macos guests
Is this not the place to report qemu bugs? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1886318 Title: Qemu after v5.0.0 breaks macos guests Status in QEMU: New Bug description: The Debian Sid 5.0-6 qemu-kvm package can no longer get further than the Clover bootloader whereas 5.0-6 and earlier worked fine. So I built qemu master from github and it has the same problem, whereas git tag v5.0.0 (or 4.2.1) does not, so something between v5.0.0 release and the last few days has caused the problem. Here's my qemu script, pretty standard macOS-Simple-KVM setup on a Xeon host: qemu-system-x86_64 \ -enable-kvm \ -m 4G \ -machine q35,accel=kvm \ -smp 4,sockets=1,cores=2,threads=2 \ -cpu Penryn,vendor=GenuineIntel,kvm=on,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc \ -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \ -smbios type=2 \ -drive if=pflash,format=raw,readonly,file="/tmp/OVMF_CODE.fd" \ -drive if=pflash,format=raw,file="/tmp/macos_catalina_VARS.fd" \ -vga qxl \ -device ich9-ahci,id=sata \ -drive id=ESP,if=none,format=raw,file=/tmp/ESP.img \ -device ide-hd,bus=sata.2,drive=ESP \ -drive id=InstallMedia,format=raw,if=none,file=/tmp/BaseSystem.img \ -device ide-hd,bus=sata.3,drive=InstallMedia \ -drive id=SystemDisk,if=none,format=raw,file=/tmp/macos_catalina.img \ -device ide-hd,bus=sata.4,drive=SystemDisk \ -usb -device usb-kbd -device usb-mouse Perhaps something has changed in Penryn support recently, as that's required for macos? See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247 Also on a related note, kernel 5.6/5.7 (on Debian) hard crashes the host when I try GPU passthrough on macos, whereas Ubuntu20/Win10 work fine - as does 5.5 kernel. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961676 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1886318/+subscriptions
[Bug 1886318] [NEW] Qemu after v5.0.0 breaks macos guests
Public bug reported: The Debian Sid 5.0-6 qemu-kvm package can no longer get further than the Clover bootloader whereas 5.0-6 and earlier worked fine. So I built qemu master from github and it has the same problem, whereas git tag v5.0.0 (or 4.2.1) does not, so something between v5.0.0 release and the last few days has caused the problem. Here's my qemu script, pretty standard macOS-Simple-KVM setup on a Xeon host: qemu-system-x86_64 \ -enable-kvm \ -m 4G \ -machine q35,accel=kvm \ -smp 4,sockets=1,cores=2,threads=2 \ -cpu Penryn,vendor=GenuineIntel,kvm=on,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc \ -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \ -smbios type=2 \ -drive if=pflash,format=raw,readonly,file="/tmp/OVMF_CODE.fd" \ -drive if=pflash,format=raw,file="/tmp/macos_catalina_VARS.fd" \ -vga qxl \ -device ich9-ahci,id=sata \ -drive id=ESP,if=none,format=raw,file=/tmp/ESP.img \ -device ide-hd,bus=sata.2,drive=ESP \ -drive id=InstallMedia,format=raw,if=none,file=/tmp/BaseSystem.img \ -device ide-hd,bus=sata.3,drive=InstallMedia \ -drive id=SystemDisk,if=none,format=raw,file=/tmp/macos_catalina.img \ -device ide-hd,bus=sata.4,drive=SystemDisk \ -usb -device usb-kbd -device usb-mouse Perhaps something has changed in Penryn support recently, as that's required for macos? See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247 Also on a related note, kernel 5.6/5.7 (on Debian) hard crashes the host when I try GPU passthrough on macos, whereas Ubuntu20/Win10 work fine - as does 5.5 kernel. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961676 ** Affects: qemu Importance: Undecided Status: New ** Also affects: debian Importance: Undecided Status: New ** No longer affects: debian -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1886318 Title: Qemu after v5.0.0 breaks macos guests Status in QEMU: New Bug description: The Debian Sid 5.0-6 qemu-kvm package can no longer get further than the Clover bootloader whereas 5.0-6 and earlier worked fine. So I built qemu master from github and it has the same problem, whereas git tag v5.0.0 (or 4.2.1) does not, so something between v5.0.0 release and the last few days has caused the problem. Here's my qemu script, pretty standard macOS-Simple-KVM setup on a Xeon host: qemu-system-x86_64 \ -enable-kvm \ -m 4G \ -machine q35,accel=kvm \ -smp 4,sockets=1,cores=2,threads=2 \ -cpu Penryn,vendor=GenuineIntel,kvm=on,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc \ -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \ -smbios type=2 \ -drive if=pflash,format=raw,readonly,file="/tmp/OVMF_CODE.fd" \ -drive if=pflash,format=raw,file="/tmp/macos_catalina_VARS.fd" \ -vga qxl \ -device ich9-ahci,id=sata \ -drive id=ESP,if=none,format=raw,file=/tmp/ESP.img \ -device ide-hd,bus=sata.2,drive=ESP \ -drive id=InstallMedia,format=raw,if=none,file=/tmp/BaseSystem.img \ -device ide-hd,bus=sata.3,drive=InstallMedia \ -drive id=SystemDisk,if=none,format=raw,file=/tmp/macos_catalina.img \ -device ide-hd,bus=sata.4,drive=SystemDisk \ -usb -device usb-kbd -device usb-mouse Perhaps something has changed in Penryn support recently, as that's required for macos? See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247 Also on a related note, kernel 5.6/5.7 (on Debian) hard crashes the host when I try GPU passthrough on macos, whereas Ubuntu20/Win10 work fine - as does 5.5 kernel. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961676 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1886318/+subscriptions
[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install
i've seen guest data corruption and qcow2 corruption on ext4. i've seen one case where the guest (win10) reports corruption but qemu- img check does not, but that's the outlier, usually both guest and qemu- img report corruption. for me the issue seems to only be win10 guests using virtio-scsi, i've not seen it on any of 25+ linux/solaris/macos/win2019 guests no matter what device driver/cache/trim i use. current workaround is convert from qcow2 to raw, everything else stays the same and i have no issues. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1847793 Title: qemu 4.1.0 - Corrupt guest filesystem after new vm install Status in QEMU: New Bug description: When I install a new vm with qemu 4.1.0 all the guest filesystems are corrupt. The first boot from the install dvd iso is ok and the installer work fine. But the guest system hangs after the installer finishes and I reboot the guest. I can see the grub boot menue but the system cannot load the initramfs. Testet with: - RedHat Enterprise Linux 7.5, 7.6 and 7.7 (RedHat uses xfs for the /boot and / partition) Guided install with the graphical installer, no lvm selected. - Debian Stable/Buster (Debian uses ext4 for / and /home partition) Guidet install with the graphical installer and default options. Used commandline to create the vm disk image: qemu-img create -f qcow2 /volumes/disk2-part2/vmdisks/vmtest10-1.qcow2 20G Used qemu commandline for vm installation: #!/bin/sh # vmtest10 Installation # /usr/bin/qemu-system-x86_64 -cpu SandyBridge-IBRS \ -soundhw hda \ -M q35 \ -k de \ -vga qxl \ -machine accel=kvm \ -m 4096 \ -display gtk \ -drive file=/volumes/disk2-part2/images/debian-10.0.0-amd64-DVD-1.iso,if=ide,media=cdrom \ -drive file=/volumes/disk2-part2/images/vmtest10-1.qcow2,if=virtio,media=disk,cache=writeback \ -boot once=d,menu=off \ -device virtio-net-pci,mac=52:54:00:2c:02:6c,netdev=vlan0 \ -netdev bridge,br=br0,id=vlan0 \ -rtc base=localtime \ -name "vmtest10" \ -usb -device usb-tablet \ -spice disable-ticketing \ -device virtio-serial-pci \ -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \ -chardev spicevmc,id=spicechannel0,name=vdagent $* Host OS: Archlinux (last updated at 10.10.2019) Linux testing 5.3.5-arch1-1-ARCH #1 SMP PREEMPT Mon Oct 7 19:03:08 UTC 2019 x86_64 GNU/Linux No libvirt in use. With qemu 4.0.0 it works fine without any errors. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1847793/+subscriptions
[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle
Can't seem to reproduce if I convert the qcow2 image to raw+sparse. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1846427 Title: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle Status in QEMU: New Bug description: 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 were found on the image. 251601/327680 = 76.78% allocated, 1.63% fragmented, 0.00% compressed clusters Image end offset: 18340446208 # bin/qemu/bin/qemu-system-x86_64 -machine pc-q35-4.0.1,accel=kvm -m 4096 -chardev stdio,id=charmonitor -mon chardev=charmonitor -drive file=debian.qcow2,id=d -S qemu-system-x86_64: warning: dbind: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. QEMU 4.1.50 monitor - type 'help' for more information (qemu) loadvm foo (qemu) c (qemu) qcow2_free_clusters failed: Invalid argument qcow2_free_clusters failed: Invalid argument qcow2_free_clusters failed: Invalid argument qcow2_free_clusters failed: Invalid argument quit [m@nargothrond:~] qemu-img check debian.qcow2 Leaked cluster 85179 refcount=2 reference=1 Leaked cluster 85180 refcount=2 reference=1 ERROR cluster 266150 refcount=0 reference=2 [...] ERROR OFLAG_COPIED data cluster: l2_entry=42284 refcount=1 9493 errors were found on the image. Data may be corrupted, or further writes to the image may corrupt it. 2 leaked clusters were found on the image. This means waste of disk space, but no harm to data. 259266/327680 = 79.12% allocated, 1.67% fragmented, 0.00% compressed clusters Image end offset: 18340446208 This is on a x86_64 Linux 5.3.1 Gentoo host with qemu-system-x86_64 and accel=kvm. The compiler is gcc-9.2.0 with the rest of the system similarly current. Reproduced with qemu-4.1.0 from distribution package as well as vanilla git checkout of tag v4.1.0 and commit 7f21573c822805a8e6be379d9bcf3ad9effef3dc (today's master). Does not happen with qemu compiled from vanilla checkout of tag v4.0.0. Build sequence: ./configure --prefix=$HOME/bin/qemu-bisect --target-list=x86_64-softmmu --disable-werror --disable-docs [...] CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g [...] (can provide full configure output if helpful) make -j8 install The kind of guest OS does not matter: seen with Debian testing 64bit, Windows 7 x86/x64 BIOS and Windows 7 x64 EFI. The virtual storage controller does not seem to matter: seen with VirtIO SCSI, emulated SCSI and emulated SATA AHCI. Caching modes (none, directsync, writeback), aio mode (threads, native) or discard (ignore, unmap) or detect-zeroes (off, unmap) does not influence occurence either. Having more RAM in the guest seems to increase odds of corruption: With 512MB to the Debian guest problem hardly occurs at all, with 4GB RAM it happens almost instantly. An automated reproducer works as follows: - the guest *does* mount its root fs and swap with option discard and my testing leaves me with the impression that file deletion rather than reading is causing the issue - foo is a snapshot of the running Debian VM which is already running command # while true ; do dd if=/dev/zero of=foo bs=10240k count=400 ; done to produce some I/O to the disk (4GB file with 4GB of RAM). - on the host a loop continuously resumes and saves the guest state and quits qemu inbetween: # while true ; do (echo loadvm foo ; echo c ; sleep 10 ; echo stop ; echo savevm foo ; echo quit ) | bin/qemu-bisect/bin/qemu-system-x86_64 -machine pc-q35-3.1,accel=kvm -m 4096 -chardev stdio,id=charmonitor -mon chardev=charmonitor -drive file=debian.qcow2,id=d -S -display none ; done - quitting qemu inbetween saves and loads seems to be necessary for the problem to occur. Just continusouly in one session saving and loading guest state does not trigger it. - For me, after about 2 to 6 iterations of above loop the image is corrupted. - corruption manifests with other messages from qemu as well, e.g.: (qemu) loadvm foo Error: Device 'd' does not have the requested snapshot 'foo' Using above reproducer I have to the be best of my ability bisected the introduction of the problem to commit 69f47505ee66afaa513305de0c1895a224e52c45 (block: avoid recursive block_status call if possible). 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
[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle
Not sure if i have exactly the same problem, as my qcow2 corruption seems to be limited to windows10 guests - win2019 and debian10 guests with the same virtio-scsi setup are fine (as are various virtio-blk or ide/sata images from linux/solaris/macos guests). I find that i randomly have disk image corruption from little more than boot/shutdown cycles - no heavy usage or anything is required. "qemu-img check -r all" usually makes things worse, as does chkdsk. host filesystem is an ssd with ext4 on top of luks, discard not used (fstrim.timer instead) with features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum Reported to redhat as assumed it was a virtio-win bug: https://bugzilla.redhat.com/show_bug.cgi?id=1762944 - includes virt- install method to reproduce my test vm's (i don't use qemu directly). Host is debian sid running qemu version 4.1.0 (Debian 1:4.1-1+b3), libvirt 5.6.0-2, kernel 5.2.0-3 (5.2.17-1) ** Bug watch added: Red Hat Bugzilla #1762944 https://bugzilla.redhat.com/show_bug.cgi?id=1762944 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1846427 Title: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle Status in QEMU: New Bug description: 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 were found on the image. 251601/327680 = 76.78% allocated, 1.63% fragmented, 0.00% compressed clusters Image end offset: 18340446208 # bin/qemu/bin/qemu-system-x86_64 -machine pc-q35-4.0.1,accel=kvm -m 4096 -chardev stdio,id=charmonitor -mon chardev=charmonitor -drive file=debian.qcow2,id=d -S qemu-system-x86_64: warning: dbind: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. QEMU 4.1.50 monitor - type 'help' for more information (qemu) loadvm foo (qemu) c (qemu) qcow2_free_clusters failed: Invalid argument qcow2_free_clusters failed: Invalid argument qcow2_free_clusters failed: Invalid argument qcow2_free_clusters failed: Invalid argument quit [m@nargothrond:~] qemu-img check debian.qcow2 Leaked cluster 85179 refcount=2 reference=1 Leaked cluster 85180 refcount=2 reference=1 ERROR cluster 266150 refcount=0 reference=2 [...] ERROR OFLAG_COPIED data cluster: l2_entry=42284 refcount=1 9493 errors were found on the image. Data may be corrupted, or further writes to the image may corrupt it. 2 leaked clusters were found on the image. This means waste of disk space, but no harm to data. 259266/327680 = 79.12% allocated, 1.67% fragmented, 0.00% compressed clusters Image end offset: 18340446208 This is on a x86_64 Linux 5.3.1 Gentoo host with qemu-system-x86_64 and accel=kvm. The compiler is gcc-9.2.0 with the rest of the system similarly current. Reproduced with qemu-4.1.0 from distribution package as well as vanilla git checkout of tag v4.1.0 and commit 7f21573c822805a8e6be379d9bcf3ad9effef3dc (today's master). Does not happen with qemu compiled from vanilla checkout of tag v4.0.0. Build sequence: ./configure --prefix=$HOME/bin/qemu-bisect --target-list=x86_64-softmmu --disable-werror --disable-docs [...] CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g [...] (can provide full configure output if helpful) make -j8 install The kind of guest OS does not matter: seen with Debian testing 64bit, Windows 7 x86/x64 BIOS and Windows 7 x64 EFI. The virtual storage controller does not seem to matter: seen with VirtIO SCSI, emulated SCSI and emulated SATA AHCI. Caching modes (none, directsync, writeback), aio mode (threads, native) or discard (ignore, unmap) or detect-zeroes (off, unmap) does not influence occurence either. Having more RAM in the guest seems to increase odds of corruption: With 512MB to the Debian guest problem hardly occurs at all, with 4GB RAM it happens almost instantly. An automated reproducer works as follows: - the guest *does* mount its root fs and swap with option discard and my testing leaves me with the impression that file deletion rather than reading is causing the issue - foo is a snapshot of the running Debian VM which is already running command # while true ; do dd if=/dev/zero of=foo bs=10240k count=400 ; done to produce some I/O to the disk (4GB file with 4GB of RAM). - on the host a loop continuously resumes and saves the guest state and quits qemu inbetween: # while true ; do (echo