From: "Michael S. Tsirkin" <mst@redhat.com>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Igor Mammedov <imammedo@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [PATCH] hw/acpi: Set memory regions to native endian as a work around
Date: Mon, 20 Feb 2023 17:33:46 -0500 [thread overview]
Message-ID: <20230220172659-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <f9f183c4-b0b8-22c6-57f9-1b6b20e8e5a5@eik.bme.hu>
On Mon, Feb 20, 2023 at 07:24:59PM +0100, BALATON Zoltan wrote:
> On Tue, 22 Feb 2022, Michael S. Tsirkin wrote:
> > On Wed, Jan 19, 2022 at 04:19:14AM -0500, Michael S. Tsirkin wrote:
> > > On Sat, Nov 13, 2021 at 07:47:20PM +0100, BALATON Zoltan wrote:
> > > > On Mon, 8 Nov 2021, BALATON Zoltan wrote:
> > > > > On Mon, 8 Nov 2021, Paolo Bonzini wrote:
> > > > > > On 11/8/21 15:30, Paolo Bonzini wrote:
> > > > > > > On 11/8/21 14:05, BALATON Zoltan wrote:
> > > > > > > > When using ACPI on big endian machine (such as ppc/pegasos2 which has
> > > > > > > > a VT8231 south bridge with ACPI) writes to ACPI registers come out
> > > > > > > > byte swapped. This may be caused by a bug in memory subsystem but
> > > > > > > > until that is fixed setting the ACPI memory regions to native endian
> > > > > > > > makes it usable for big endian machines. This fixes ACPI shutdown with
> > > > > > > > pegasos2 when using the board firmware for now.
> > > > > > > > This could be reverted when the memory layer is fixed.
> > > > > > >
> > > > > > > What is the path to the swapped writes? Even just a backtrace
> > > > > > > might be enough to understand what's going on, and especially
> > > > > > > where the bug is.
> > > > > >
> > > > > > Ok, Michael pointed me at https://lore.kernel.org/all/20211011080528-mutt-send-email-mst@kernel.org/.
> > > >
> > > > Ping? I haven't seen an alternative fix yet. If you don't have time now this
> > > > could be postponed to next version with the native endian work around for
> > > > now.
> > > >
> > > > Regards,
> > > > BALATON Zoltan
> > >
> > > Paolo, ping?
> >
> > ping
>
> Can this be fixed please or my proposed workaround taken until it will be?
> Original patch I've sent is here:
> http://patchew.org/QEMU/20211108130934.59B48748F52@zero.eik.bme.hu/
>
> I hope to make pegasos2 more usable in next release so maybe more people
> will want to use it soon.
>
> Regards,
> BALATON Zoltan
Any chance of fixing it in memory core? No one else seems to care.
I think fundamentally you need to check for the condition
Size < mr->ops->impl.min_access_size in memory_region_dispatch_write
and then make a read, combine the result with
the value and make a write.
> > > > > I was about to say that here's the original thread:
> > > > >
> > > > > https://lists.nongnu.org/archive/html/qemu-devel/2021-10/msg01972.html
> > > > >
> > > > > and here's the backtrace:
> > > > >
> > > > > #0 acpi_pm1_cnt_write (val=40, ar=0x55555695f340) at ../hw/acpi/core.c:556
> > > > > #1 acpi_pm_cnt_write (opaque=0x55555695f340, addr=1, val=40, width=2)
> > > > > at ../hw/acpi/core.c:602
> > > > > #2 0x0000555555b3a82f in memory_region_write_accessor
> > > > > (mr=mr@entry=0x55555695f590, addr=1,
> > > > > value=value@entry=0x7fffefffdd08, size=size@entry=2, shift=<optimized
> > > > > out>, mask=mask@entry=65535, attrs=...)
> > > > > at ../softmmu/memory.c:492
> > > > > #3 0x0000555555b3813e in access_with_adjusted_size
> > > > > (addr=addr@entry=1, value=value@entry=0x7fffefffdd08,
> > > > > size=size@entry=1, access_size_min=<optimized out>,
> > > > > access_size_max=<optimized out>, access_fn=
> > > > > 0x555555b3a7b0 <memory_region_write_accessor>, mr=0x55555695f590,
> > > > > attrs=...) at ../softmmu/memory.c:554
> > > > > #4 0x0000555555b3c449 in memory_region_dispatch_write
> > > > > (mr=mr@entry=0x55555695f590, addr=1, data=<optimized out>, op=<optimized
> > > > > out>, attrs=attrs@entry=...)
> > > > > at ../softmmu/memory.c:1511
> > > > > #5 0x0000555555b2c121 in flatview_write_continue
> > > > > (fv=fv@entry=0x7fff84d23b30, addr=addr@entry=4261416709,
> > > > > attrs=attrs@entry=..., ptr=ptr@entry=0x7fffefffdec0, len=len@entry=1,
> > > > > addr1=<optimized out>,
> > > > > l=<optimized out>, mr=0x55555695f590) at host-utils.h:165
> > > > > #6 0x0000555555b2c399 in flatview_write (len=1, buf=0x7fffefffdec0,
> > > > > attrs=..., addr=4261416709, fv=0x7fff84d23b30) at
> > > > > ../softmmu/physmem.c:2822
> > > > > #7 subpage_write (opaque=<optimized out>, addr=<optimized out>,
> > > > > value=<optimized out>, len=1, attrs=...) at ../softmmu/physmem.c:2488
> > > > > #8 0x0000555555b380de in access_with_adjusted_size
> > > > > (addr=addr@entry=3845, value=value@entry=0x7fffefffdf88,
> > > > > size=size@entry=1, access_size_min=<optimized out>,
> > > > > access_size_max=<optimized out>, access_fn=
> > > > > 0x555555b3aa80 <memory_region_write_with_attrs_accessor>,
> > > > > mr=0x7fff84710bb0, attrs=...) at ../softmmu/memory.c:549
> > > > > #9 0x0000555555b3c449 in memory_region_dispatch_write
> > > > > (mr=mr@entry=0x7fff84710bb0, addr=addr@entry=3845, data=<optimized out>,
> > > > > data@entry=40, op=op@entry=MO_8, attrs=...)
> > > > > at ../softmmu/memory.c:1511
> > > > > #10 0x0000555555c07b4c in io_writex
> > > > > (env=env@entry=0x55555666a820,
> > > > > iotlbentry=iotlbentry@entry=0x7fff843367f0, mmu_idx=1, val=val@entry=40,
> > > > > addr=addr@entry=4261416709,
> > > > > retaddr=retaddr@entry=140736116523268, op=MO_8) at
> > > > > ../accel/tcg/cputlb.c:1420
> > > > > #11 0x0000555555c0b5df in store_helper (op=MO_8, retaddr=<optimized
> > > > > out>, oi=<optimized out>, val=40, addr=4261416709, env=0x55555666a820)
> > > > > at ../accel/tcg/cputlb.c:2355
> > > > > #12 full_stb_mmu (env=0x55555666a820, addr=4261416709, val=40,
> > > > > oi=<optimized out>, retaddr=140736116523268) at
> > > > > ../accel/tcg/cputlb.c:2404
> > > > > #13 0x00007fffae3b8104 in code_gen_buffer ()
> > > > > #14 0x0000555555bfcfab in cpu_tb_exec (cpu=cpu@entry=0x555556661360,
> > > > > itb=itb@entry=0x7fffae3b7fc0 <code_gen_buffer+56197011>,
> > > > > tb_exit=tb_exit@entry=0x7fffefffe668)
> > > > > at ../accel/tcg/cpu-exec.c:357
> > > > > #15 0x0000555555bfe089 in cpu_loop_exec_tb (tb_exit=0x7fffefffe668,
> > > > > last_tb=<synthetic pointer>, tb=0x7fffae3b7fc0
> > > > > <code_gen_buffer+56197011>, cpu=0x555556661360)
> > > > > at ../accel/tcg/cpu-exec.c:833
> > > > > #16 cpu_exec (cpu=cpu@entry=0x555556661360) at ../accel/tcg/cpu-exec.c:992
> > > > > #17 0x0000555555c1bba0 in tcg_cpus_exec (cpu=cpu@entry=0x555556661360)
> > > > > at ../accel/tcg/tcg-accel-ops.c:67
> > > > > #18 0x0000555555c1c3d7 in rr_cpu_thread_fn
> > > > > (arg=arg@entry=0x555556661360) at ../accel/tcg/tcg-accel-ops-rr.c:214
> > > > > #19 0x0000555555d5c049 in qemu_thread_start (args=0x7fffefffe750) at
> > > > > ../util/qemu-thread-posix.c:556
> > > > > #20 0x00007ffff6a95dea in start_thread () at /lib64/libpthread.so.0
> > > > > #21 0x00007ffff69c8fdf in clone () at /lib64/libc.so.6
> > > > >
> > >
> >
> >
next prev parent reply other threads:[~2023-02-20 22:34 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-08 13:05 [PATCH] hw/acpi: Set memory regions to native endian as a work around BALATON Zoltan
2021-11-08 13:32 ` Michael S. Tsirkin
2021-11-08 15:22 ` BALATON Zoltan
2021-12-16 10:27 ` Michael S. Tsirkin
2021-11-08 14:30 ` Paolo Bonzini
2021-11-08 15:04 ` Paolo Bonzini
2021-11-08 15:16 ` BALATON Zoltan
2021-11-13 18:47 ` BALATON Zoltan
2022-01-19 9:19 ` Michael S. Tsirkin
2022-02-22 14:40 ` Michael S. Tsirkin
2023-02-20 18:24 ` BALATON Zoltan
2023-02-20 22:33 ` Michael S. Tsirkin [this message]
2023-02-20 23:25 ` BALATON Zoltan
2023-02-21 8:30 ` Paolo Bonzini
2023-02-21 12:48 ` BALATON Zoltan
2023-02-21 12:55 ` BALATON Zoltan
2023-03-06 22:56 ` Paolo Bonzini
2023-03-06 23:11 ` BALATON Zoltan
2023-03-06 23:36 ` Paolo Bonzini
2023-03-07 0:06 ` BALATON Zoltan
2023-03-07 5:58 ` Paolo Bonzini
2023-03-07 10:01 ` BALATON Zoltan
2023-03-07 11:26 ` Paolo Bonzini
2023-03-07 12:54 ` BALATON Zoltan
2023-03-07 15:14 ` Paolo Bonzini
2023-03-07 15:21 ` BALATON Zoltan
2023-03-07 16:48 ` Paolo Bonzini
2023-04-30 23:10 ` BALATON Zoltan
2023-04-30 23:26 ` BALATON Zoltan
2023-02-21 14:02 ` Paolo Bonzini
2023-03-02 13:42 ` BALATON Zoltan
2023-03-06 18:34 ` Michael S. Tsirkin
2023-03-03 8:22 ` Michael S. Tsirkin
2023-03-11 20:59 ` 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=20230220172659-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=balaton@eik.bme.hu \
--cc=imammedo@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 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.