Re: [PATCH 3/5] KVM: PPC: Book3S HV: Improve handling of local vs. global TLB invalidations

Paul Mackerras
2012-11-23T22:07:01Z

On Fri, Nov 23, 2012 at 04:43:03PM +0100, Alexander Graf wrote:
>
> On 22.11.2012, at 10:28, Paul Mackerras wrote:
>
> > - With the possibility of the host paging out guest pages, the use of
> > H_LOCAL by an SMP guest is dangerous since the guest could possibly
> > retain and use a stale TLB entry pointing to a page that had been
> > removed from the guest.
>
> I don't understand this part. Don't we flush the TLB when the page gets evicted from the shadow HTAB?

The H_LOCAL flag is something that we invented to allow the guest to
tell the host "I only ever used this translation (HPTE) on the current
vcpu" when it's removing or modifying an HPTE. The idea is that that
would then let the host use the tlbiel instruction (local TLB
invalidate) rather than the usual global tlbie instruction. Tlbiel is
faster because it doesn't need to go out on the fabric and get
processed by all cpus. In fact our guests don't use it at present,
but we put it in because we thought we should be able to get a
performance improvement, particularly on large machines.

However, the catch is that the guest's setting of H_LOCAL might be
incorrect, in which case we could have a stale TLB entry on another
physical cpu. While the physical page that it refers to is still
owned by the guest, that stale entry doesn't matter from the host's
point of view. But if the host wants to take that page away from the
guest, the stale entry becomes a problem.

The solution I implement here is just not to use tlbiel in SMP guests.
UP guests are not so much of a problem because the potential attack
from the guest relies on having one cpu remove the HPTE and do tlbiel
while another cpu uses the stale TLB entry, which you can't do if you
only have one cpu.

Paul.