[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Allow acpi-tmr size=2
From: |
Michael Tokarev |
Subject: |
Re: [PATCH] Allow acpi-tmr size=2 |
Date: |
Mon, 13 Jul 2020 17:16:56 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
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
Re: [PATCH] Allow acpi-tmr size=2, Michael S. Tsirkin, 2020/07/14