Re: ACPI endianness

[BALATON Zoltan]

On Sun, 10 Oct 2021, Michael S. Tsirkin wrote:
> On Sun, Oct 10, 2021 at 03:24:32PM +0200, BALATON Zoltan wrote:
> > Hello,
> >
> > I'm trying to fix shutdown and reboot on pegasos2 which uses ACPI as part of
> > the VIA VT8231 (similar to and modelled in hw/isa/vt82c686b.c) and found
> > that the guest writes to ACPI PM1aCNT register come out with wrong
> > endianness but not shure why. I have this:
> >
> > $ qemu-system-ppc -M pegasos2 -monitor stdio
> > (qemu) info mtree
> > [...]
> > memory-region: pci1-io
> >   0000000000000000-000000000000ffff (prio 0, i/o): pci1-io
> > [...]
> >     0000000000000f00-0000000000000f7f (prio 0, i/o): via-pm
> >       0000000000000f00-0000000000000f03 (prio 0, i/o): acpi-evt
> >       0000000000000f04-0000000000000f05 (prio 0, i/o): acpi-cnt
> >       0000000000000f08-0000000000000f0b (prio 0, i/o): acpi-tmr
> >
> > memory-region: system
> >   0000000000000000-ffffffffffffffff (prio 0, i/o): system
> >     0000000000000000-000000001fffffff (prio 0, ram): pegasos2.ram
> >     0000000080000000-00000000bfffffff (prio 0, i/o): alias pci1-mem0-win 
> > @pci1-mem 0000000080000000-00000000bfffffff
> >     00000000c0000000-00000000dfffffff (prio 0, i/o): alias pci0-mem0-win 
> > @pci0-mem 00000000c0000000-00000000dfffffff
> >     00000000f1000000-00000000f100ffff (prio 0, i/o): mv64361
> >     00000000f8000000-00000000f8ffffff (prio 0, i/o): alias pci0-io-win @pci0-io 
> > 0000000000000000-0000000000ffffff
> >     00000000f9000000-00000000f9ffffff (prio 0, i/o): alias pci0-mem1-win 
> > @pci0-mem 0000000000000000-0000000000ffffff
> >     00000000fd000000-00000000fdffffff (prio 0, i/o): alias pci1-mem1-win 
> > @pci1-mem 0000000000000000-0000000000ffffff
> >     00000000fe000000-00000000feffffff (prio 0, i/o): alias pci1-io-win @pci1-io 
> > 0000000000000000-0000000000ffffff
> >     00000000ff800000-00000000ffffffff (prio 0, i/o): alias pci1-mem3-win 
> > @pci1-mem 00000000ff800000-00000000ffffffff
> >     00000000fff00000-00000000fff7ffff (prio 0, rom): pegasos2.rom
> >
> > The guest (which is big endian PPC and I think wotks on real hardware)
> > writes to 0xf05 in the io region which should be the high byte of the little
> > endian register but in the acpi code it comes out wrong, instead of 0x2800 I
> > get in acpi_pm1_cnt_write: val=0x28
> >
> > The memory regions involved are:
> >
> > acpi-cnt (hw/acpi/core.c):
> >
> > static const MemoryRegionOps acpi_pm_cnt_ops = {
> >     .read = acpi_pm_cnt_read,
> >     .write = acpi_pm_cnt_write,
> >     .impl.min_access_size = 2,
> >     .valid.min_access_size = 1,
> >     .valid.max_access_size = 2,
> >     .endianness = DEVICE_LITTLE_ENDIAN,
> > };
> >
> > via-pm (hw/isa/vt82c686.c):
> >
> > static const MemoryRegionOps pm_io_ops = {
> >     .read = pm_io_read,
> >     .write = pm_io_write,
> >     .endianness = DEVICE_NATIVE_ENDIAN,
> >     .impl = {
> >         .min_access_size = 1,
> >         .max_access_size = 1,
> >     },
> > };
> >
> > Also tried removing .impl from pm_io_ops but that does not help. Changing
> > acpi_pm_cnt_ops to DEVICE_NATIVE_ENDIAN fixes it but not sure what else
> > could that break. Should these ACPI regions be native endian or how else to
> > fix this for the vt82xx case?
> >
> > Regards,
> > BALATON Zoltan
>
> Does it help if you change via to DEVICE_LITTLE_ENDIAN?

No. That region is just acting as a container for the ACPI regions so they 
can be moved together to the base address settable by the guest (and maybe 
implementing some other regs later if needed but we don't do that now) but 
looks like it's not involved in read/write to acpi regs as its ops are not 
called and the write goes through to the acpi-cnt region. So it also does 
not matter if I change endianness or impl in pm_io_ops in vt82c686.c.

These acpi bits only seem to be used on piix4 and ich9 apart from vt82xx 
and those are probably used on little endian hosts while vt8231 is used on 
pegasos2 which is big endian PPC and vt82c686b on fullong2e which I think 
is little endian MIPS. What does NATIVE_ENDIAN actually mean? It does not 
seem to be documented anywhere. Would it change anything if the ACPI 
regions are changed ro NATIVE_ENDIAN for little endian machines that are 
all the other usages? If not then maybe that's the way to go.

Regards,
BALATON Zoltan