Re: [Qemu-devel] [RFC 00/20] Do away with TB retranslation

[Richard Henderson <rth@twiddle.net>]

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~