Re: [Qemu-devel] [PATCH v9 40/84] target/mips: Fix pre-nanoMIPS MT ASE instructions availability control

[Aleksandar Markovic]

> From: Richard Henderson <address@hidden>
> Sent: Thursday, August 16, 2018 6:37 PM
> 
> Subject: Re: [PATCH v9 40/84] target/mips: Fix pre-nanoMIPS MT ASE 
> instructions availability control
> 
> On 08/16/2018 07:57 AM, Aleksandar Markovic wrote:
> > From: Aleksandar Rikalo <address@hidden>
> >
> > Use bits from configuration registers for availability control
> > of MT ASE instructions, rather than only ISA_MT bit in insn_flags.
> > This is done by adding a field in hflags for MT bit, and adding
> > functions check_mt() and check_cp0_mt().
> >
> > Reviewed-by: Aleksandar Markovic <address@hidden>
> > Signed-off-by: Aleksandar Markovic <address@hidden>
> > Signed-off-by: Stefan Markovic <address@hidden>
> > ---
> >  target/mips/cpu.h       |  3 ++-
> >  target/mips/internal.h  |  6 +++++-
> >  target/mips/translate.c | 45 +++++++++++++++++++++++++++++++++++++--------
> >  3 files changed, 44 insertions(+), 10 deletions(-)
> 
> What was wrong with using insn_flags?
> 

The problem with using ISA_MT from insn_flags is that it doesn't provide the 
correct availability control. Even though all instructions from MT ASE are 
related, they are available under different conditions:

Case 1 - DMT, DVPE, EMT, EVPE:
    
    if IsCoprocessorEnabled(0) then
        if Config3 MT then
            <main fuctionality>
        else
            SignalException(ReservedInstruction)
        endif
    else
        SignalException(CoprocessorUnusable, 0)
    endif

Case 2 - FORK, YIELD:

    if Config3 MT then
        <main fuctionality>
    else
        SignalException(ReservedInstruction)
    endif

Case 3 - MFTR, MTTR:

    if IsCoprocessorEnabled(0) then
        <main fuctionality>
    else
        SignalException(CoprocessorUnusable, 0)
    endif

> I'll note that hflags should be reserved for things that can change at 
> runtime.
>  I thought all of these configuration registers were read-only.
> 
> Anyway, with this plus the XNP patch from earlier, you now only have one
> remaining bit within hflags and then that resource is exhausted.
> 

I think some of the previously-implemented similar cases involving read-only 
bits were handled the same way, and we just built on that. What would you 
suggest as a more appropriate solution in such cases (of accessing "preset by 
hardware" bits)?

Regards,
Aleksandar