[hppa-linux] Picky details of TLB fault handlers

[hppa-linux] Picky details of TLB fault handlers

[Christopher Neufeld]

   Here's a question probably best suited for the folks at HP. The
PA-RISC 2.0 documentation says that a (software) TLB miss fault handler
cannot use virtual addressing. OK, what constitutes an exit from the
handler? Can you use virtual addressing after the last modification the
handler makes to the TLB (perhaps after executing several instructions
which don't require virtual addressing to load the pipeline), or do you
have to execute an explicit return from interrupt?


-- 
 Christopher Neufeld                   neufeld@physics.utoronto.ca
 Home page:  http://caliban.physics.utoronto.ca/neufeld/Intro.html
 "Don't edit reality for the sake of simplicity"

Re: [hppa-linux] Picky details of TLB fault handlers

[Bjorn Helgaas]

Christopher Neufeld wrote
>
>The PA-RISC 2.0 documentation says that a (software) TLB miss fault handler
>cannot use virtual addressing. OK, what constitutes an exit from the
>handler? Can you use virtual addressing after the last modification the
>handler makes to the TLB (perhaps after executing several instructions
>which don't require virtual addressing to load the pipeline), or do you
>have to execute an explicit return from interrupt?

I think you just have to make sure that you can recover from all the
TLB miss faults you might encounter.  In order to recover, you need the
program counter at the time the trap occurred.  If the PSW Q-bit was set
at the time of interruption, the PSW and program counter are captured in
the IPSW and IIA queues, and the PSW Q-bit is cleared.  When you do the
RFI to "return from interrupt", the PSW and program counter with which
to resume are taken from from the IPSW and IIA queues.

So the software TLB miss handler runs with the Q-bit off.  If another
interruption occurred with the Q-bit off, the IPSW and IIA queues
would still reflect the point of the original TLB miss, *not* the point
where the second interruption occurred, and you would have to think very
carefully about whether this is what you want.  If the second interruption
happened to be another TLB miss, you would not get the ISR/IOR (because
the Q-bit was off), so it would be pretty tough to handle it.

You can certainly save the IPSW and IIA queues somewhere, then turn on
the Q-bit, go virtual, and do your interrupt handling in virtual mode.
In this case, you will execute an RFI just in order to turn on the Q-bit,
but the program counter at which to resume will be somewhere in the
interrupt handler, not the point where the original interruption occurred.
When you eventually finish the interrupt handler, you look up your saved
IPSW and IIA queues and do another RFI to return "for real".

HP-UX does exactly this sort of thing for handling many traps and
interrupts.  It is fairly expensive, though, since you have to have
a stack on which to save the IPSW/IIAQ and probably a bunch of other
registers, and it's too much messing around for a TLB miss.

-------------
Bjorn Helgaas   helgaas@rsn.hp.com  telnet 1-497-3069  (972)497-3069

Re: [hppa-linux] Picky details of TLB fault handlers

[Michael Shalayeff]

Making, drinking tea and reading an opus magnum from Alan Cox:
> > HP-UX does exactly this sort of thing for handling many traps and
> > interrupts.  It is fairly expensive, though, since you have to have
> > a stack on which to save the IPSW/IIAQ and probably a bunch of other
> > registers, and it's too much messing around for a TLB miss.
> 
> I'm right in assuming its legal to swap the return address - so the TLB
> handler can do a short piece of TLB handling for a present page miss,
> then stash the return into the kernel stack and rfi into the page fault handler
> so it will in turn return to the user context ?

i'd say that a miss handler would not _ever_ exceed 100 instructions total time
to successfully lookup and insert a missing translation into a tlb and
using just shadowed registers, so by doing that w/ all the interrupts
disabled (and keeping some data in direct-mapped segment) no need
to save even a single bit of context (since it's all in the shadows).
then the handler can save the whole context and call pagefault() routine to
process a complex page fault (ie one that has no translation
in the page table), since the whole context is saved it's safe to
receive any other page faults and/or interrupts.

this schema was first implemented in the lites (and mklinux later).
doing this way is like simulating the hardware TLB walker as present
on certain machines (712 at least, maybe any 7100lc, HP help!?)
there are certain constraints on page table organization, but
doing so would greatly speed up the tlb-walker equipped machines,
leaving the rest still in the best shape possible.
building a tlb-walker-ONLY kernel (as an option) may save about 10 other
instructions.

cu

-- 
    paranoic mickey       (my employers have changed but, the name has remained)

Re: [hppa-linux] Picky details of TLB fault handlers

[Alan Cox]

> HP-UX does exactly this sort of thing for handling many traps and
> interrupts.  It is fairly expensive, though, since you have to have
> a stack on which to save the IPSW/IIAQ and probably a bunch of other
> registers, and it's too much messing around for a TLB miss.

I'm right in assuming its legal to swap the return address - so the TLB
handler can do a short piece of TLB handling for a present page miss,
then stash the return into the kernel stack and rfi into the page fault handler
so it will in turn return to the user context ?

Alan

Re: [hppa-linux] Picky details of TLB fault handlers

[Bjorn Helgaas]

>I'm right in assuming its legal to swap the return address - so the TLB
>handler can do a short piece of TLB handling for a present page miss,
>then stash the return into the kernel stack and rfi into the page fault handler
>so it will in turn return to the user context ?

Yes.