As found in LP#964247, MacOS Catalina performs 2-byte reads
on the acpi timer address space while the spec says it should
be 4-byte. Allow 2-byte reads.
Reported-By: Simon John <git@the-jedi.co.uk>
Signed-Off-By: Michael Tokarev <mjt@tls.msk.ru>
---
hw/acpi/core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
I'm applying this to debian qemu package, need the fix
faster in order to release security updates for other
branches.
diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index 45cbed49ab..9be38aa2ac 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -530,7 +530,9 @@ 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,
+ .impl.min_access_size = 4,
+ /* at least MacOS Catalina reads 2 bytes and fails if it doesn't work */
+ .valid.min_access_size = 2,
.valid.max_access_size = 4,
.endianness = DEVICE_LITTLE_ENDIAN,
};
--
2.20.1
On Tue, Jul 14, 2020 at 12:55:18PM +0300, Michael Tokarev wrote: > As found in LP#964247, MacOS Catalina performs 2-byte reads > on the acpi timer address space while the spec says it should > be 4-byte. Allow 2-byte reads. > > Reported-By: Simon John <git@the-jedi.co.uk> > Signed-Off-By: Michael Tokarev <mjt@tls.msk.ru> After some thought, I think I'll do a 1-byte one the way Simon proposed. Just go back to behave the way it did. Will apply yours on top - Simon - could you try and send a tested-by tag please? > --- > hw/acpi/core.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > I'm applying this to debian qemu package, need the fix > faster in order to release security updates for other > branches. > > diff --git a/hw/acpi/core.c b/hw/acpi/core.c > index 45cbed49ab..9be38aa2ac 100644 > --- a/hw/acpi/core.c > +++ b/hw/acpi/core.c > @@ -530,7 +530,9 @@ 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, > + .impl.min_access_size = 4, > + /* at least MacOS Catalina reads 2 bytes and fails if it doesn't work */ > + .valid.min_access_size = 2, > .valid.max_access_size = 4, > .endianness = DEVICE_LITTLE_ENDIAN, > }; > -- > 2.20.1
On 7/14/20 11:55 AM, Michael Tokarev wrote: > As found in LP#964247, MacOS Catalina performs 2-byte reads > on the acpi timer address space while the spec says it should > be 4-byte. Allow 2-byte reads. https://bugs.launchpad.net/qemu/+bug/964247 is about Unity-2D shell... What is the target hardware used here? > > Reported-By: Simon John <git@the-jedi.co.uk> > Signed-Off-By: Michael Tokarev <mjt@tls.msk.ru> > --- > hw/acpi/core.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > I'm applying this to debian qemu package, need the fix > faster in order to release security updates for other > branches. > > diff --git a/hw/acpi/core.c b/hw/acpi/core.c > index 45cbed49ab..9be38aa2ac 100644 > --- a/hw/acpi/core.c > +++ b/hw/acpi/core.c > @@ -530,7 +530,9 @@ 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, > + .impl.min_access_size = 4, > + /* at least MacOS Catalina reads 2 bytes and fails if it doesn't work */ > + .valid.min_access_size = 2, > .valid.max_access_size = 4, > .endianness = DEVICE_LITTLE_ENDIAN, > }; >
14.07.2020 13:26, Philippe Mathieu-Daudé пишет: > On 7/14/20 11:55 AM, Michael Tokarev wrote: >> As found in LP#964247, MacOS Catalina performs 2-byte reads >> on the acpi timer address space while the spec says it should >> be 4-byte. Allow 2-byte reads. > > https://bugs.launchpad.net/qemu/+bug/964247 is about Unity-2D shell... It's a debian bug# ( http://bugs.debian.org/964247 ), not LP, the right LP bug is LP#1886318 . Mixed the two wrongly, I'm sorry for that. I resent a v2, also allowing 1-byte access as suggested by mst. > What is the target hardware used here? It's x86. Thanks, /mjt
On 7/14/20 12:55 PM, Michael Tokarev wrote: > 14.07.2020 13:26, Philippe Mathieu-Daudé пишет: >> On 7/14/20 11:55 AM, Michael Tokarev wrote: >>> As found in LP#964247, MacOS Catalina performs 2-byte reads >>> on the acpi timer address space while the spec says it should >>> be 4-byte. Allow 2-byte reads. >> >> https://bugs.launchpad.net/qemu/+bug/964247 is about Unity-2D shell... > > It's a debian bug# ( http://bugs.debian.org/964247 ), not LP, the > right LP bug is LP#1886318 . Mixed the two wrongly, I'm sorry for that. Ah, no worry. Please include in the tags: BugLink: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247 > I resent a v2, also allowing 1-byte access as suggested by mst. > >> What is the target hardware used here? > > It's x86. > > Thanks, > > /mjt >
Patchew URL: https://patchew.org/QEMU/20200714095518.16241-1-mjt@msgid.tls.msk.ru/ Hi, This series seems to have some coding style problems. See output below for more information: Type: series Message-id: 20200714095518.16241-1-mjt@msgid.tls.msk.ru Subject: [PATCH for-5.1] acpi-pm-tmr: allow 2-byte reads === TEST SCRIPT BEGIN === #!/bin/bash git rev-parse base > /dev/null || exit 0 git config --local diff.renamelimit 0 git config --local diff.renames True git config --local diff.algorithm histogram ./scripts/checkpatch.pl --mailback base.. === TEST SCRIPT END === Switched to a new branch 'test' b4f3ad8 acpi-pm-tmr: allow 2-byte reads === OUTPUT BEGIN === ERROR: The correct form is "Signed-off-by" #12: Signed-Off-By: Michael Tokarev <mjt@tls.msk.ru> total: 1 errors, 0 warnings, 10 lines checked Commit b4f3ad8f13df (acpi-pm-tmr: allow 2-byte reads) has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. === OUTPUT END === Test command exited with code: 1 The full log is available at http://patchew.org/logs/20200714095518.16241-1-mjt@msgid.tls.msk.ru/testing.checkpatch/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-devel@redhat.com
© 2016 - 2024 Red Hat, Inc.