Re: [PATCH] hw/acpi: Set memory regions to native endian as a work around

[BALATON Zoltan <balaton@eik.bme.hu>]

[-- Attachment #1: Type: text/plain, Size: 3331 bytes --]

On Tue, 7 Mar 2023, Paolo Bonzini wrote:
> On 3/7/23 13:54, BALATON Zoltan wrote:
>>> evt 3 1 write 1      // enable timer
>>> evt 0 2 read
>>> evt 0 2 write 1      // just writes again the same value, clearing sts
>>> 
>>> I am quite confident that the second guess is correct, because "write the 
>>> same value that was read" only makes sense for evt_sts and not for evt_en.
>> 
>> It could also make sense if the guest is trying to flip a bit that's 
>> already set or cleared.
>
> No, I checked what the guest actually does and it's read followed immediately 
> by a write, with no other ALU values in the middle.
>
>> AFAIU the device is little endian (VT8231 is a PCI device and primarily a 
>> PC part so it's expected to be little endian) but the guest also knows this 
>> and writes byte swaped values to it. But since the memory region is set to 
>> LITTLE_ENDIAN and we're on a big endian CPU QEMU will byte swap it again 
>> which it should not do as the guest already did that.
>
> It's the opposite.
>
> The CPU first swaps the value that was in the register, when it executes 
> sthbrx instructions.  With DEVICE_LITTLE_ENDIAN, QEMU does the second swap 
> and restores the value that was in the register.  With DEVICE_NATIVE_ENDIAN 
> it happens to fix the cases that matter for your testcase, but it breaks 
> others.
>
>>> This means that the first write is almost certainly to evt_en.  On a 
>>> little-endian machine the write would set bit 8 of evt.en (power button), 
>>> but what about a big-endian machine like yours?  Should it set bit 0 or 
>>> bit 8? If it's bit 0 (which resides at offset 2 according to the device), 
>>> who flips the low bit of the address?  Why is bit 0 flipped but not bit 1?
>> 
>> I think the guest already writes byte swapped value so it should work the 
>> same as on little endian machine but the QEMU memory layer gets in the way.
>
> The write in question is "evt addr=3 size=1 value=1" so it's a one-byte 
> write.  There's no byte swapping involved here, rather the question is how 
> the addresses are interpreted.
>
>>> - get a real machine, and figure out whether the write to offset 3 
>>> corresponds to the PM timer or the power button.
>> 
>> I don't have real machine but know somebody who does but I'm not sure what 
>> to ast to test on it. Can you describe it what you want to see or maybe 
>> write a sctipt for the fimrware to test it (if you're familiar enough with 
>> Forth for that). I can try to find some more info on this but so far I was 
>> concentrating on other bigger issues. This is a minor annoyance but would 
>> be nice to fix eventually.
>
> I didn't even have an idea that Forth was involved, honestly, or how to write 
> Forth code for this machine that I barely know exists. :)

It's supposed to be CHRP compatible which mandates OpenFirmware so it 
should work about the same as similar IBM and Apple machines but those are 
also kind of obscure. If you can describe what you want tested I can try 
to make that a script and ask somebody to run it on real machine but I'm 
not sure what to test.

Regards,
BALATON Zoltan

>>> - continue the trace up to the point the OS runs, and see if you get some 
>>> clues similar to the one above that placed evt_sts at offset 2.
>
> I'll try this once the machine is back in shape.
>
> Paolo
>
>