Re: [PATCH 07/23] Add SLB switching code for entry/exit

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Tue, 2009-07-07 at 16:17 +0200, Alexander Graf wrote:
> This is the really low level of guest entry/exit code.
> 
> Usually the Linux kernel resides in virtual memory 0xc000000000000000 to
> 0xffffffffffffffff. These addresses are mapped into every userspace
> application.
> 
> When going into a 32 bit guest, this is perfectly fine. That one can't
> access memory that high anyways.
> 
> Going into a 64 bit guest, the guest kernel probably is in the same
> virtual memory region as the host, so we need to switch between those two.
> 
> During normal entry code we're in those virtual addresses though. So
> we need a small wrapper in real memory that switches from host to guest
> high SLB state and vice versa.
> 
> To store both host and guest state in the SLB, we store guest kernel SLB
> entries in a different range (0x40000000000000000 - 0x7ffffffffffffffff).
> 
> For details on which entries go where, please see the patch itself.

Note that we have an unused VSID bit at the moment on 64-bit afaik. We
could probably use that to differenciate guest kernel VSIDs from host
kernel VSIDs. That would avoid having to muck around with the EAs
themselves that much no ?

I'm not sure I understand exactly what you are doing here, we should
discuss this on IRC one of these days I suppose. But you should be able
to just get rid of the host kernel SLBs completely with some care, as
there are some critical code path where taking an exception without
having the SLB entry around for entry 0 and the kernel stack will
blow...

But just blow them off, and when returning to the kernel, just put back
the ones that are needed (aka slb_flush_and_rebolt). You will need to
play carefully with that though, look at the code in slb.c, as the real
pHyp hypervisor that may lie underneath will potentially muck around the
SLBs and will restore them occasionally from the special in-memory
shadows, so you probably want to switch the content of those too.

Of course none of that will work on legacy iSeries or Power3 but I think
we can safely say we don't care :-)

Cheers,
Ben.