From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37270) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zc8YZ-0006UO-Jh for qemu-devel@nongnu.org; Wed, 16 Sep 2015 04:59:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zc8YW-0007Sj-AU for qemu-devel@nongnu.org; Wed, 16 Sep 2015 04:59:11 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:34252) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zc8YW-0007SR-3h for qemu-devel@nongnu.org; Wed, 16 Sep 2015 04:59:08 -0400 Received: by wicfx3 with SMTP id fx3so62682590wic.1 for ; Wed, 16 Sep 2015 01:59:06 -0700 (PDT) References: <1441173123-25540-1-git-send-email-rth@twiddle.net> <87r3m685pg.fsf@linaro.org> <55F87D53.1060108@twiddle.net> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <55F87D53.1060108@twiddle.net> Date: Wed, 16 Sep 2015 09:59:04 +0100 Message-ID: <8737yeoi3r.fsf@linaro.org> MIME-Version: 1.0 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: Richard Henderson Cc: dl.soluz@gmx.net, qemu-devel@nongnu.org, aurelien@aurel32.net, atar4qemu@gmail.com Richard Henderson writes: > 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? I unfortunately haven't got a SPARC manual handy (or my old testsuite) but I was sure there was more than just loads/stores. I guess all the FP related exceptions are handled in Softfloat for QEMU and the hardcoded cases caught during instruction decode. >> * 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. Sure - more instrumentation and data would be useful for this. It's an area I'd like to look at once MTTCG is done as I think the next wins are going to be in code generation and optimization. >> * 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. The eternal problem ;-) I'll send an email to my old employer and see if the unit tests can be liberated. The worst that could happen is they say no. > > > r~ -- Alex Bennée