Excerpts from Christophe Leroy's message of January 3, 2021 3:56 am: > Nicholas Piggin <npig...@gmail.com> a écrit : > >> The page fault handling still has some complex logic particularly around >> hash table handling, in asm. Implement this in C instead. > > Hi, > > I'm afk at the moment and unable to look at this in details before one > week but this looks pretty complexe, especially the churn around > ___do_page_fault > Do we really need 3 layers of do_page_fault() ?
Actually it doesn't, patch 10 wants it. I can move it to there at least which should make this a bit less churn. It's convenient because lots of return paths in __do_page_fault, but I could try convert that to a `goto out` style. > I think it would likely be more straight forward to just move > handle_page_fault() to C. The hash fault stuff makes things work better this way. Perhaps if I can get to the bottom of the context tracking in the hash fault (I think we perhaps should avoid it), then it could go back to a common code path. > There also seems to be some unrelated changes, like the (msr & MSR_PR) > changed to user_mode(regs). That's part of making it callable from asm and the radix vs hash prototypes the same so there are no added complexity in the asm: >> @@ -1439,13 +1440,17 @@ EXC_COMMON_BEGIN(data_access_common) >> GEN_COMMON data_access >> ld r4,_DAR(r1) >> ld r5,_DSISR(r1) >> + addi r3,r1,STACK_FRAME_OVERHEAD >> BEGIN_MMU_FTR_SECTION >> - ld r6,_MSR(r1) >> - li r3,0x300 >> - b do_hash_page /* Try to handle as hpte fault */ >> + bl do_hash_fault >> MMU_FTR_SECTION_ELSE >> - b handle_page_fault >> + bl do_page_fault >> ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_TYPE_RADIX) I'll see if anything can be done to move some such changes ahead. Thanks, Nick
