From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44691) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbwhX-0001PL-PR for qemu-devel@nongnu.org; Tue, 15 Sep 2015 16:19:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbwhT-0007gA-Qf for qemu-devel@nongnu.org; Tue, 15 Sep 2015 16:19:39 -0400 Received: from mail-qg0-x234.google.com ([2607:f8b0:400d:c04::234]:34992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbwhT-0007fy-IA for qemu-devel@nongnu.org; Tue, 15 Sep 2015 16:19:35 -0400 Received: by qgt47 with SMTP id 47so153711517qgt.2 for ; Tue, 15 Sep 2015 13:19:34 -0700 (PDT) Sender: Richard Henderson References: <1441173123-25540-1-git-send-email-rth@twiddle.net> <87r3m685pg.fsf@linaro.org> From: Richard Henderson Message-ID: <55F87D53.1060108@twiddle.net> Date: Tue, 15 Sep 2015 13:19:31 -0700 MIME-Version: 1.0 In-Reply-To: <87r3m685pg.fsf@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC 00/20] Do away with TB retranslation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Alex_Benn=c3=a9e?= Cc: dl.soluz@gmx.net, qemu-devel@nongnu.org, aurelien@aurel32.net, atar4qemu@gmail.com On 09/10/2015 11:55 AM, Alex Bennée wrote: > I've only had a quick glance so far but I'm fairly familiar with the > concept from a previous life. I'll aim to do a full review later once > I've gotten through my MTTCG review backlog. > > Anyway some quick points: > > * You can save data by only marking faulting instructions > > Assuming that all asynchronous instructions trigger at the end/prologue > of basic blocks you only actually need to record the address of > potentially faulting instructions. In fact only a few backend > instructions will actually synchronously fault. > > Of course this does have the downside of having to mark all those > instructions in the front end. We have that. The only tcg opcodes that can fault are qemu_ld, qemu_st, and call. So, yes, I could do exactly this. Perhaps not for round 1, however? > * This method can also be used for additional rectification data > > AIUI we currently ensure all load/stores are barriers and ensure the CPU > register file is updated before the occur. However if you wanted to you > could drop that requirement and mark the target-host register pair and > only fish it out when required on a fault. Maybe. I'd have to think about this. We'd probably want to study how many flushes to the register file this could elide. My off-the-cuff guess is not enough to make the extra overhead useful. > * Test suites are essential if your going to get clever > > Last time I went through this I built a SPARC test suite to cover all > faulting instructions in all the various addressing modes. It flushed > out a lot of bugs. Indeed. It would indeed be good to add a bunch of bare-metal tests. Pre-compiled and checked in so that one doesn't have to have a suite of cross-compilers in order to use them. OTOH, I don't see myself (or anyone else) really having the time to do that. r~