On Wed, 11 Apr 2018 11:32:12 +1000
Benjamin Herrenschmidt <benh@xxxxxxxxxxx> wrote:
> On Tue, 2018-04-10 at 22:48 +1000, Nicholas Piggin wrote:
> >
> > + /*
> > + * Do we need to flush the TLB for the LPAR? (see TLB comment above)
> > + * On POWER9, individual threads can come in here, but the
> > + * TLB is shared between the 4 threads in a core, hence
> > + * invalidating on one thread invalidates for all.
> > + * Thus we make all 4 threads use the same bit here.
> > + */
>
> This might be true of P9 implementation but isn't architecturally
> correct. From an ISA perspective, the threads could have dedicatd
> tagged TLB entries. Do we need to be careful here vs. backward
> compatiblity ?
I think so. I noticed that, just trying to do like for like replacement
with this patch.
Yes it should have a feature bit test for this optimization IMO. That
can be expanded if other CPUs have the same ability... Is it even
a worthwhile optimisation to do at this point, I wonder? I didn't see
it being hit a lot in traces.
> Also this won't flush ERAT entries for another thread afaik.
Yeah, I'm still not entirely clear exactly when ERATs get invalidated.
I would like to see more commentary here to show why it's okay.
>
> > + tmp = pcpu;
> > + if (cpu_has_feature(CPU_FTR_ARCH_300))
> > + tmp &= ~0x3UL;
> > + if (cpumask_test_cpu(tmp, &vc->kvm->arch.need_tlb_flush)) {
> > + if (kvm_is_radix(vc->kvm))
> > + radix__local_flush_tlb_lpid(vc->kvm->arch.lpid);
> > + else
> > + hash__local_flush_tlb_lpid(vc->kvm->arch.lpid);
> > + /* Clear the bit after the TLB flush */
> > + cpumask_clear_cpu(tmp, &vc->kvm->arch.need_tlb_flush);
> > + }
> > +
>
--
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
