From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZF92E-0001u4-Gd for qemu-devel@nongnu.org; Tue, 14 Jul 2015 18:50:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZF92A-0003wm-Ik for qemu-devel@nongnu.org; Tue, 14 Jul 2015 18:50:46 -0400 Received: from gate.crashing.org ([63.228.1.57]:49259) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZF92A-0003vl-9A for qemu-devel@nongnu.org; Tue, 14 Jul 2015 18:50:42 -0400 Message-ID: <1436914234.3948.276.camel@kernel.crashing.org> From: Benjamin Herrenschmidt Date: Wed, 15 Jul 2015 08:50:34 +1000 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] TLB, cpu_mmu_index() and load/store vs ifetch List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Alexander Graf Cc: qemu-devel@nongnu.org Hi Paolo, Alex ! I was looking at the patches for speeding up ppc and was trying to figure out if we could do things better, and reduce the number of modes and flushes associated with them. While trying to understand it all, I found something that might be a problem: How we handle the fact that we can separately turn on/off translation on ppc for I and D side. However, unless I missed something, qemu currently uses the same helper to retrieve the mmu index for load/stores and instruction fetches. Now, the TLB entry itself has different addresses for code, read and write so it works. However that means that we have to use modes for every combination of IR and DR in the MSR, which seems like quite a waste. IE, ignoring PR and HV we already have 4 modes. Would it be possible to have the target optionally provide a separate accessor cpu_mmu_index_code() instead and use it in the few places that actually try to fetch instructions such as get_page_addr_code() ? That would allow us in effect to have just a single mode entry for "real mode" (or two if we add support for HV) and simply point to it appropriately for data or instructions separately. Is there any reason why that wouldn't work ? I don't yet pretend to fully understand that part of qemu/tcg :-) Anything I have overlooked ? (Before I start hacking ...) Cheers, Ben.