qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PATCH 02/17] ppc: avoid excessive TLB flush


From: David Gibson
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH 02/17] ppc: avoid excessive TLB flushing
Date: Fri, 5 Sep 2014 16:00:28 +1000
User-agent: Mutt/1.5.23 (2014-03-12)

On Thu, Aug 28, 2014 at 09:35:27PM +0200, Paolo Bonzini wrote:
> Il 28/08/2014 19:30, Peter Maydell ha scritto:
> > On 28 August 2014 18:14, Paolo Bonzini <address@hidden>
> wrote:
[snip]
> > Does PPC hardware do lots of TLB flushes on user-kernel
> > transitions, or does it have some sort of info in the TLB
> > entry about whether it should match or not?
> 
> The IR and DR bits simply disable paging for respectively instructions
> and data.  I suppose real hardware simply does not use the TLB when
> paging is disabled.

That's right for the most part, although IR and DR transitions are
still pretty horribly slow, due to the various synchronizations that
need to happen.

There are some other complications though.  At least POWER7 and POWER8
supports a "virtual real mode area" (VRMA, which is where a guest OS
sees itself as having translation off, but in fact translations
(managed by the hypervisor) are still in use.  In the (hashed) page
table the VRMA co-exists with the guest's normal translations.  I'm
not up to date with the TLB architecture and how it's impacted.  Note
that POWER chips (since POWER4?) have both the ERAT (which is what
most cpus would think of as fast but smallish TLB) and the TLB which
is a sort of L1.5 cache, which needs to be combined with the SLB to
form full translations.  I strongly suspect the ERAT does need to be
flushed on real-mode/virtual-mode transitions, but I'm less sure about
the SLB and TLB.

As yet another case, BookE (embedded) powerpc CPUs have IS/DS bits
instead of IR/DR, reflecting that instead of a true "translation off"
mode, they have two different "address spaces".  In this case,
however, the address space is tagged into the TLB, so the whole thing
doesn't need to be flushed on address space transitions.

> IIRC each user->kernel transition disables paging, and then the kernel
> can re-enable it (optionally only on data).  So the transition is
> user->kernel unpaged->kernel paged, and the kernel unpaged->kernel paged
> part is what triggers the TLB flush.  (Something like this---Alex
> explained it to me a year ago when I asked why tlb_flush was always the
> top function in the profile of qemu-system-ppc*).
> 
> Paolo
> 

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: pgpcMkHKsF74e.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]