On Wed, 2008-09-10 at 10:54 +0800, Liu Yu-B13201 wrote:
> > The shadow TLB allows us to skip the repopulation phase, but at the
> > expense of some memory and some overhead on every exit. Also, it's
> > difficult or impossible to implement a shadow TLB on cores where
> > software cannot address TLB entries by index (i.e. the hardware
> > automatically selects the index).
>
> Shadow TLB also avoid recalculation, the value of shadow tlb entry can
> be directly written into hardware.
> And get and put page can be save as well.
>
> btw, why do we need to update TLB on every exit, why can't we just
> update it on miss?
Linux can actually modify the host TLB at any time. For example, if
Linux gets a fault touching vmalloc'ed memory, or printk faults trying
to touch the UART, a new host TLB entry will be inserted without the
knowledge of KVM.
If that happens though, it's just clobbered a guest TLB entry, so we put
it back. Ideally we don't want to reload the *entire* TLB, only entries
that the host has changed, but I think that optimization is not yet
implemented. That's what this comment is about:
/* Save the host's non-pinned TLB mappings, and load the guest mappings
* over them. Leave the host's "pinned" kernel mappings in place. */
/* XXX optimization: use generation count to avoid swapping unmodified
* entries. */
> > If we did remove the shadow TLB, I think we'd suffer even more TLB
> > misses, so we'd need to really optimize our TLB miss handler.
>
> Could you give more pros. about removing the shadow TLB?
> To make TLB handler can fit more processors?
Yeah, to more easily adapt the 440 handler to similar cores I guess.
Well, also I really want to minimize the impact of a TLB miss. We get a
*lot* of them, and without huge page support in the host we get way more
than Linux on native hardware would.
> > Logically speaking, our TLB miss handler must do the following:
> > 1. walk guest TLB(s) to find a matching entry
>
> If we implement large guest TLB in the future,
> we might need to involve advanced data structure such as rb-tree.
Absolutely, and I guess e500 (2048-entry TLB0) already has this problem
worse than 440 (64-entry TLB). I'll let you submit a patch for that. ;)
--
Hollis Blanchard
IBM Linux Technology Center
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
