Re: [PATCH v2 for-5.1] acpi-pm-tmr: allow any small-size reads

2020-07-14 Thread Simon John 

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

2020-07-14 Thread Simon John 
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

2020-07-13 Thread Simon John 

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

2020-07-13 Thread Simon John 
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

2020-07-12 Thread Simon John 
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

2020-07-12 Thread Simon John 
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

2020-07-12 Thread Simon John 
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

2020-07-12 Thread Simon John 
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

2020-07-12 Thread Simon John 
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

2020-07-12 Thread Simon John 
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

2020-07-11 Thread Simon John 
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

2020-07-11 Thread Simon John 
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

2020-07-11 Thread Simon John 
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

2020-07-11 Thread Simon John 
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

2020-07-11 Thread Simon John 
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

2020-07-11 Thread Simon John 
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

2020-07-11 Thread Simon John 
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

2020-07-05 Thread Simon John 
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

2019-10-21 Thread Simon John 
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

2019-10-20 Thread Simon John 
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

2019-10-20 Thread Simon John 
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