qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 20/27] target/sparc: Convert to CPUClass::tlb


From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH v2 20/27] target/sparc: Convert to CPUClass::tlb_fill
Date: Thu, 9 May 2019 08:51:23 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 5/9/19 6:35 AM, Peter Maydell wrote:
>> +    if (probe) {
>> +        return false;
>> +    }
>> +
>> +    if (env->mmuregs[3]) { /* Fault status register */
>> +        env->mmuregs[3] = 1; /* overflow (not read before another fault) */
>> +    }
>> +    env->mmuregs[3] |= (access_index << 5) | error_code | 2;
>> +    env->mmuregs[4] = address; /* Fault address register */
>> +
>> +    if (access_type == MMU_INST_FETCH) {
>> +        cs->exception_index = TT_TFAULT;
>> +    } else {
>> +        cs->exception_index = TT_DFAULT;
>> +    }
>> +    cpu_loop_exit_restore(cs, retaddr);
>>  }
> 
> ...but in the new code we only set them if we're really
> going to fault.

Yes, I made change assuming that would allow probe to work, which would seem to
require that the FSR not be modified.

> The v8 SPARC architecture manual appending H says that
> when the NF bit is 1 faults detected by the MMU cause
> FSR and FAR to be updated even though no fault is generated
> to the processor. So I think the change here is not correct.
> 
> (The spec also says that ASI 9 is supposed to be special and
> not affected by NF==1; and I think that since we put entries in
> the TLB for the NF case we won't correctly set the fault address
> register if the CPU makes two successive accesses to the same
> page, because the second access won't take the slow path and
> won't update the FAR. But those are pre-existing bugs.)

Thanks for the pointers.  They do look like pre-existing bugs.

I think the only thing to do for sparc is the same as i386 -- assert that probe
is unset.  If someone ever decides to use tlb_vaddr_to_host from the sparc
backend, they'll have to come back and untangle this.


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]