From: BALATON Zoltan <balaton@eik.bme.hu>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Igor Mammedov" <imammedo@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
qemu-devel@nongnu.org, pbonzini@redhat.com
Subject: Re: ACPI endianness
Date: Mon, 11 Oct 2021 19:47:59 +0200 (CEST) [thread overview]
Message-ID: <864f1144-b2ba-c5ab-cff2-2fce3518f4ab@eik.bme.hu> (raw)
In-Reply-To: <20211011115521-mutt-send-email-mst@kernel.org>
On Mon, 11 Oct 2021, Michael S. Tsirkin wrote:
> On Mon, Oct 11, 2021 at 03:51:01PM +0200, BALATON Zoltan wrote:
>>> ... but given we did not previously do the read, maybe we should keep
>>> it that way at least for the time being.
>>
>> How do you know there was no read before this write? Did you check it? I've
>> only added a printf in the write method and saw the value was swapped but
>> did not check if there was a read before that. There are no traces in these
>> methods so maybe I would not see it unless adding a printf there too.
>
> All I am saying is that qemu did not convert a write into
> a read+write.
OK confirmed that by disabling pm_io_space_update() in hw/isa/vt82c686.c
so the via-pm region is never mapped and then modifying the log messages
for invalid accesses (patch sent separately) I get:
~ # poweroff
Sent SIGKILL to all processes
Requesting system poweroff
pci_cfg_write vt82c686b-usb-uhci 12:3 @0xc0 <- 0x8f00
pci_cfg_write vt82c686b-usb-uhci 12:2 @0xc0 <- 0x8f00
[ 16.498465] reboot: Power down
Invalid write at addr 0xFE000F05, size 1, region '(null)', reason: rejected
Invalid write at addr 0xF05, size 1, region '(null)', reason: rejected
So the guest only tries to write one byte but not sure if the read
generated within memory.c would show up in these logs. I suspect if you
fixed that you'd get all sorts of problems with other device models so the
less likely to break anything fix would be to go back to native endian for
acpi but I wait for what you come up with. I'd like this to be fixed one
way or another for 6.2 and fixing endianness would probably be enough for
that.
Regards,
BALATON Zoltan
next prev parent reply other threads:[~2021-10-11 17:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-10 13:24 ACPI endianness BALATON Zoltan
2021-10-10 14:03 ` Michael S. Tsirkin
2021-10-10 14:26 ` BALATON Zoltan
2021-10-11 5:52 ` Philippe Mathieu-Daudé
2021-10-11 10:13 ` BALATON Zoltan
2021-10-11 12:19 ` Michael S. Tsirkin
2021-10-11 13:14 ` Jonathan Cameron
2021-10-11 13:27 ` BALATON Zoltan
2021-10-11 13:34 ` Michael S. Tsirkin
2021-10-11 13:51 ` BALATON Zoltan
2021-10-11 15:55 ` Michael S. Tsirkin
2021-10-11 17:47 ` BALATON Zoltan [this message]
2021-10-25 15:05 ` BALATON Zoltan
2021-10-25 17:10 ` Michael S. Tsirkin
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=864f1144-b2ba-c5ab-cff2-2fce3518f4ab@eik.bme.hu \
--to=balaton@eik.bme.hu \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.