On Thu, Feb 15, 2024 at 10:09:42PM -0800, Guenter Roeck wrote: > 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. Tangential question, but why does Linux need to save and restore the PSW if that is already handled by the hardware? I am missing something. - Charlie > > > 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 >
