From: BALATON Zoltan <balaton@eik.bme.hu>
To: Igor Mammedov <imammedo@redhat.com>
Cc: qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Ani Sinha <anisinha@redhat.com>
Subject: Re: [PATCH] hw/acpi: Fix PM control register access
Date: Tue, 6 Jun 2023 18:59:48 +0200 (CEST) [thread overview]
Message-ID: <1639953d-6f1c-cd9c-bba5-bc3b0b9134f1@eik.bme.hu> (raw)
In-Reply-To: <20230606145046.159b6bba@imammedo.users.ipa.redhat.com>
On Tue, 6 Jun 2023, Igor Mammedov wrote:
> On Sun, 28 May 2023 15:57:50 +0200 (CEST)
> BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
>> On pegasos2 which has ACPI as part of VT8231 south bridge the board
>> firmware writes PM control register by accessing the second byte so
>> addr will be 1. This wasn't handled correctly and the write went to
>> addr 0 instead. This fixes ACPI shutdown with pegasos2 firmware.
>>
>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>> ---
>> This is replacing the previous attempt which changed enduanness to
>> NATIVE_ENDIAN that was found to be wrong. I'm still not sure what's
>> happening as these functions are called with addr = 1 and size = 2 but
>> maybe the guest really does word access to addr 1 when wanting to
>> write 1 byte. This fixes the problem and should not break anything
>> else but please review.
>>
>> hw/acpi/core.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/acpi/core.c b/hw/acpi/core.c
>> index 6da275c599..bbc599a252 100644
>> --- a/hw/acpi/core.c
>> +++ b/hw/acpi/core.c
>> @@ -593,13 +593,13 @@ void acpi_pm1_cnt_update(ACPIREGS *ar,
>> static uint64_t acpi_pm_cnt_read(void *opaque, hwaddr addr, unsigned width)
>> {
>> ACPIREGS *ar = opaque;
>> - return ar->pm1.cnt.cnt;
>> + return ar->pm1.cnt.cnt >> addr * 8;
>> }
> that looks fine
>
>>
>> static void acpi_pm_cnt_write(void *opaque, hwaddr addr, uint64_t val,
>> unsigned width)
>> {
>> - acpi_pm1_cnt_write(opaque, val);
>> + acpi_pm1_cnt_write(opaque, val << addr * 8);
>> }
> however, if this is 1 byte write at offset 1,
> wouldn't this wipe out lower byte
> (aka:
> #define ACPI_BITMASK_SCI_ENABLE 0x0001
> #define ACPI_BITMASK_BUS_MASTER_RLD 0x0002
> #define ACPI_BITMASK_GLOBAL_LOCK_RELEASE 0x0004
> )?
Since this will either reset or power off the machine it probably does not
really matter. But to fix that more we'd need to rewrite
acpi_pm1_cnt_write() to replace acpi_pm_cnt_write() and handle that
internally. Or is there another way to handle this? Does that worth the
effort when the only known usage is in pegasos2 firmware when it calls
power off?
Regards,
BALATON Zoltan
next prev parent reply other threads:[~2023-06-06 17:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-28 13:57 [PATCH] hw/acpi: Fix PM control register access BALATON Zoltan
2023-06-05 22:01 ` BALATON Zoltan
2023-06-06 12:50 ` Igor Mammedov
2023-06-06 16:59 ` BALATON Zoltan [this message]
2023-06-07 14:26 ` Igor Mammedov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1639953d-6f1c-cd9c-bba5-bc3b0b9134f1@eik.bme.hu \
--to=balaton@eik.bme.hu \
--cc=anisinha@redhat.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).