[Qemu-devel] [sparc32] do_unassigned_access vs. cpu_sparc_handle_mmu_fault

[Qemu-devel] [sparc32] do_unassigned_access vs. cpu_sparc_handle_mmu_fault

[Artyom Tarasenko]

The function do_unassigned_access in op_helper.c looks very similar
 to the function cpu_sparc_handle_mmu_fault in helper.c and it is
called after the later one.

Why do we need to set env->mmuregs[3] and env->mmuregs[4]  twice?
Setting the SFSR and SFAR in do_unassigned_access looks redundant to
me and actually the second setting env->mmuregs[3] will also set the
overflow flag and therefore produce a wrong result.

Also

env->mmuregs[4] = addr;

looks wrong because addr is definied as target_phys_addr_t, so there
is a cast to the smaller uint_32 type.

If I remove the suspicious code from do_unassigned_access I can boot
Solaris 2.6.
Shall I produce a patch for 0.12?

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/

[Qemu-devel] Re: [sparc32] do_unassigned_access vs. cpu_sparc_handle_mmu_fault

[Blue Swirl]

On Wed, Dec 16, 2009 at 7:11 PM, Artyom Tarasenko
<atar4qemu@googlemail.com> wrote:
> The function do_unassigned_access in op_helper.c looks very similar
>  to the function cpu_sparc_handle_mmu_fault in helper.c and it is
> called after the later one.
>
> Why do we need to set env->mmuregs[3] and env->mmuregs[4]  twice?
> Setting the SFSR and SFAR in do_unassigned_access looks redundant to
> me and actually the second setting env->mmuregs[3] will also set the
> overflow flag and therefore produce a wrong result.
>
> Also
>
> env->mmuregs[4] = addr;
>
> looks wrong because addr is definied as target_phys_addr_t, so there
> is a cast to the smaller uint_32 type.
>
> If I remove the suspicious code from do_unassigned_access I can boot
> Solaris 2.6.
> Shall I produce a patch for 0.12?

Please do, though as 0.12.0 has been tagged, it may be 0.12.1 material
or just for HEAD.