13.07.2020 10:20, Michael Tokarev пишет: > 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 <kra...@redhat.com> > Date: Thu Nov 22 12:12:30 2012 +0100 > Subject: apci: switch timer to memory api > Signed-off-by: Gerd Hoffmann <kra...@redhat.com> > > 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?
Actually it is more twisted than that. We can't just change the size, we must update the corresponding code too. static uint64_t acpi_pm_tmr_read(void *opaque, hwaddr addr, unsigned width) { return acpi_pm_tmr_get(opaque); } note the actual read function does not even know neither the requested address nor the requested width, it assumes the min/max constraints are enforced and the read goes to all 4 bytes. If this pm timer can be read byte-by-byte, we should return the right byte of the value, not always the whole value. /mjt