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

[Alex Bennée]

Richard Henderson <address@hidden> 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