After the recent shenanigans regarding macos VFIO being broken in 5.6/5.7 kernels, the Debian qemu 5.0-6 package stopped booting macos whatsoever!

Rolling back to 5.0-5 fixes things, as does compiling from source the release tagged v5.0.0 or even v4.2.1

So I raised a bug report to the Debian packagers, who identified the patches they got from upstream since 5.0-5 but with no real idea which one broke things.

Next I raised a bug on the upstream qemu launchpad where they recommended a git bisect, which basically consists of working backwards from git/master to tag/v5.0.0 compiling and testing and marking each commit group as good or bad, until you get through all of the commits and end up with the culprit, basically this in a loop:

git bisect bad
./configure --target-list=x86_64-softmmu && make -j32
git bisect good

And wow does 32 cores come in handy there - compiled qemu in around 10secs!

Eventually it identified commit 5d971f9e6725 which translates to Debian patch revert-memory-accept-mismatching-sizes-in-memory_region_access_valid-CVE-2020-13754.patch, I built a set of Debian packages of 5.0-6 without that patch so that I could still use virt-manager instead of qemu scripts, and all is good, but wow did those Xeon’s get hot - both at 79-82c!

sudo apt build-dep qemu
apt source qemu
sed -i 's/revert-memory-accept-mismatching-sizes-in-memory_region_access_valid-CVE-2020-13754.patch//' qemu-5.0/debian/patches/series
debuild -us -uc
sudo dpkg -i qemu-system-x86_5.0-6_amd64.deb
sudo apt-mark hold qemu-system-x86

In the bug report some debugging was suggested, and we found that on an unpatched master, the output was this over and over:

invalid size: acpi-tmr addr 0 size: 2

From some grep’ing I found that acpi-tmr resides in hw/acpi/core.c and it is indeed limited to a value of 4, so 2 won’t work, well we can fix that!

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,
 };

So I submitted my patch upstream to hopefully get it included in 5.1

As the patch that broke things was a security patch, I don’t expect the Debian packagers will remove it (it fixes some other things globally, just breaks ACPI locally), so we’ll probably have to wait for 5.1 for my upstream patch.

Quite an enjoyable exercise though. Now we just need to get the kernel issue fixed although I doubt there’s anyone working on that, hopefully it’ll get fixed by coincidence (like whilst fixing something else) for 5.8, there’s no way I’m bisecting from 5.5 to 5.6 with the host crashing every time! I even tried OpenCore instead of Clover, but that made no difference.