2. The next mmu implementation, which caches guest translations.Don't understand. Can't one CPU cause a TLB entry to be flushed on all
The potential problem above now becomes acute. The guest will have kernel mappings for every page, and after a short while they'll all be faulted in and locked. This defeats the swap integration which is IMO a very strong point.
We can work around that by periodically forcing out translations (some kind of clock algorithm) at some rate so the host vm can have a go at them. That can turn out to be expensive as we'll need to interrupt all running vcpus to flush (real) tlb entries.
CPUs?
It's not about tlb entries. The shadow page tables collaples a GV -> HV -> HP double translation into a GV -> HP page table. When the Linux vm goes around evicting pages, it invalidates those mappings.
There are two solutions possible: lock pages which participate in these translations (and their number can be large) or modify the Linux vm to consult a reverse mapping and remove the translations (in which case TLB entries need to be removed).