On Mon, Jul 13, 2020 at 05:16:56PM +0300, Michael Tokarev wrote: > 13.07.2020 15:17, Michael S. Tsirkin пишет: > > On Mon, Jul 13, 2020 at 12:46:00PM +0100, Simon John wrote: > >> 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? > > It's not about the security fix, it's about the piece in qemu code which > behaved wrongly for several years, which finally started to actually work. > > >> 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. > >> > > > > Sounds good. And how about also adding: > > What this call will receive on a real HW? returning the same 4 bytes > even when asked for 2 smells wrong, no? > > > .impl.min_access_size = 4, > > What does it mean? :) > > /mjt
This will allow you to return a 4 byte value and will shift it accordingly. See: docs/devel/memory.rst : - .impl.min_access_size, .impl.max_access_size define the access sizes (in bytes) supported by the *implementation*; other access sizes will be emulated using the ones available. For example a 4-byte write will be emulated using four 1-byte writes, if .impl.max_access_size = 1. -- MST