Re: ACPI endianness

[BALATON Zoltan]

On Mon, 11 Oct 2021, Philippe Mathieu-Daudé wrote:
> On 10/10/21 15:24, 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
>
> Looks like a northbridge issue (MV64340).
> Does Pegasos2 enables bus swapping?
> See hw/pci-host/mv64361.c:585:
>
> static void warn_swap_bit(uint64_t val)
> {
>    if ((val & 0x3000000ULL) >> 24 != 1) {
>        qemu_log_mask(LOG_UNIMP, "%s: Data swap not implemented", __func__);
>    }
> }

No, guests don't use this feature just byteswap themselves and write 
little endian values to the mapped io region. (Or in this case just write 
one byte of the 16 bit value, it specifically writes 0x28 to 0xf05.) 
That's why I think the device model should not byteswap itself so the acpi 
regions should be declared native endian and let the guest handle it. Some 
mentions I've found say that native endian means don't byteswap, little 
endian means byteswap if vcpu is big endian and big endian means byteswap 
if vcpu is little endian. Since guests already account for this and write 
little endian values to these regions there's no need to byteswap in 
device model and changing to native endian should not affect little endian 
machines so unless there's a better argument I'll try sending a patch.

Regards,
BALATON Zoltan