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. -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
