On 2/15/24 21:54, Helge Deller wrote:
[ ... ]
Can you please give a pointer to this test code?
I'm happy to try it on real hardware.
You should also see the problem if you use v7 of Charlie's checksum
unit test fixes.
I submitted the qemu fix (or at least what I think the fix should be)
a couple of minutes ago.
https://patchwork.kernel.org/project/qemu-devel/patch/20240216053415.2163286-1-linux@xxxxxxxxxxxx/
It is quite easy to show that carry is always set after executing ldd
on an unaligned address. That is also why I know for sure that the
problem is not seen with ldw on unaligned addresses.
Interesting.
Ultimately it wasn't surprising, with the unusual carry bit
implementation on hppa. The upper 8 carry bits were not masked
correctly when returning from a trap or interrupt.
In general I think it's quite important to differentiate between
running on qemu or running on physical hardware.
I know, that makes testing always tricky (not just with this
architecture) because it is often not obvious if the problem
is a problem in the tested code or a problem in the emulation.
Qemu just recently got 64-bit support, and it's not yet behaving
like real hardware. One thing I noticed is, that read hardware
does not seem to jump into the exception handler twice, while
qemu does. So, if you run into an exception (e.g. unaligned ldd)
then if a second exception happens in the fault handler (e.g. second
unaligned ldd to resolve wrongly-coded code lookup), you will
get different behaviour between hardware and emulation.
Hmm, interesting. Makes me wonder how the real hardware handles such
double traps.
This is also the reason why qemu still fails to emulate newer
64-bit Linux kernels which uses kernel modules.
I don't use modules in my testing, so I'll leave that alone for
anther day.
Cheers,
Guenter
