On 8/9/24 06:52, Guenter Roeck wrote:
On 8/8/24 11:19, Linus Torvalds wrote:
On Thu, 8 Aug 2024 at 10:48, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
Here is the disassembly from my latest crashing debug kernel which
shifts it up a couple of pages. Add 0x10 or sub 0x20 to make it work.
Looks like I was off by an instruction, it's the 28th divide-step (not
29) that does the page crosser:
4121dffc: 0b 21 04 41 ds r1,r25,r1
4121e000: 0b bd 07 1d add,c ret1,ret1,ret1
but my parisc knowledge is not good enough to even guess at what could go wrong.
And I have no actual reason to believe this has *anything* to do with
an itlb miss, except for that whole "exact placement seems to matter,
and it crosses a page boundary" detail.
None of this makes sense. I think we'll have to wait for Helge. It's
not like parisc is a huge concern, and for all we know this is all a
qemu bug to begin with.
Copying Richard Henderson who recently made a number of changes to the
parisc/hppa qemu implementation (which unfortunately didn't fix the problem).
Wow, that's quite the agile bug you've got there.
You can eliminate one class of qemu bug by attempting to reproduce in qemu-linux-user:
arrange for the page crossing at the appropriate spot and see if the split between two
translation blocks causes carry flag weirdness.
If that doesn't reproduce, then I'd be likely to blame something in the exception delivery
or return process. Still could be a qemu problem, but it would be something in the system
emulation of the exception path.
It should be possible to write a small system mode test case for this hypothesis. Ideally
the itlb miss handler would be as simple a possible, e.g. computing an identity mapping
rather than using real page tables.
Only after that would I start digging into the linux kernel's exception paths.
r~
