From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48436) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPmci-0002Gp-PH for qemu-devel@nongnu.org; Fri, 05 Sep 2014 02:03:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPmcf-0005fD-4i for qemu-devel@nongnu.org; Fri, 05 Sep 2014 02:03:52 -0400 Date: Fri, 5 Sep 2014 16:00:28 +1000 From: David Gibson Message-ID: <20140905060028.GB29795@voom.redhat.com> References: <1409246113-6519-1-git-send-email-pbonzini@redhat.com> <1409246113-6519-3-git-send-email-pbonzini@redhat.com> <53FF847F.7060400@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LyciRD1jyfeSSjG0" Content-Disposition: inline In-Reply-To: <53FF847F.7060400@redhat.com> Subject: Re: [Qemu-devel] [PATCH 02/17] ppc: avoid excessive TLB flushing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Tom Musta , Peter Maydell , "qemu-ppc@nongnu.org" , QEMU Developers , dgibson@redhat.com --LyciRD1jyfeSSjG0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 > 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? >=20 > 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*). >=20 > Paolo >=20 --=20 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 --LyciRD1jyfeSSjG0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUCVF8AAoJEGw4ysog2bOSsuMP/1zrgx7Ep0JnHoGh+cMwMtjV 8XxGraWcNzAWcVfKA6dwgxx9P0h1b06qouV9K4zc6lrpjGVieTtoDojEYDGq9seI Zq418+pLxehul77HZzsF7dtht1EUe2kfk3+HJICa/teeVs/TK2b6hnf7cHNuL8En p5cmlUIP6UNQmKfj1p7locRNdqOoossNQCcSfm32Hzyulw+XqTFIDoUMjOXNgjDj uZcdQ5XmG8RDdMwmLm3qhWZaWkqjrL2hmsVmpf4ZmfVrOUCbQwsEwGNSAKDANfjN C3NXKCwuD9HQY3QKUCHUDp3AOxMIvhYVk7GxjjvVNjzzfzTW1VCHc0V4+3n/Kzjs j99HYK/s25dJbmdoWs1t5EsZ27eMdRurjgxA1QIkuErOqjaLbyS5cW5b4rt/Sknf AA83yHbfFnHmEvWaNu8J2YLILhPEyxvUGnauVaUoaYzhKVLXLOqM0tGCxzUcD/Hf mtJ8QSnZtQ5D4qo9GQJMzbKWID+er8ZAVODJ/04Z1xxX19g3J5qkqhaWCFbHP267 qYruo3Y+3ZDKpUl3BQEFekKOdyPIo85lqsnGUKEE9+A5IUdaNT8EhcWqhTevpPNn f6apMXrhEHS7s8ro74SABYT016dpNT+BCthBuKCNPZhVIcF++vfcH4wdpbdk12/V Ubg1/6lEJuzX93dgkhzU =nson -----END PGP SIGNATURE----- --LyciRD1jyfeSSjG0--