[Qemu-devel] [PATCH] target-mips: Fix RDHWR on CP0.Count

[Qemu-devel] [PATCH] target-mips: Fix RDHWR on CP0.Count

[Alex Smith]

For RDHWR on the CP0.Count register, env->CP0_Count was being returned.
This value is a delta against the QEMU_CLOCK_VIRTUAL clock, not the
correct current value of CP0.Count. Use cpu_mips_get_count() instead.

Signed-off-by: Alex Smith <alex.smith@imgtec.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Leon Alrae <leon.alrae@imgtec.com>
---
 target-mips/op_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
index 809a061e296b..6fe00201c10d 100644
--- a/target-mips/op_helper.c
+++ b/target-mips/op_helper.c
@@ -2185,7 +2185,7 @@ target_ulong helper_rdhwr_cc(CPUMIPSState *env)
 {
     if ((env->hflags & MIPS_HFLAG_CP0) ||
         (env->CP0_HWREna & (1 << 2)))
-        return env->CP0_Count;
+        return (int32_t)cpu_mips_get_count(env);
     else
         helper_raise_exception(env, EXCP_RI);
 
-- 
2.5.0

Re: [Qemu-devel] [PATCH] target-mips: Fix RDHWR on CP0.Count

[Leon Alrae]

On 04/09/15 09:21, Alex Smith wrote:
> For RDHWR on the CP0.Count register, env->CP0_Count was being returned.
> This value is a delta against the QEMU_CLOCK_VIRTUAL clock, not the
> correct current value of CP0.Count. Use cpu_mips_get_count() instead.
> 
> Signed-off-by: Alex Smith <alex.smith@imgtec.com>
> Cc: Aurelien Jarno <aurelien@aurel32.net>
> Cc: Leon Alrae <leon.alrae@imgtec.com>
> ---
>  target-mips/op_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
> index 809a061e296b..6fe00201c10d 100644
> --- a/target-mips/op_helper.c
> +++ b/target-mips/op_helper.c
> @@ -2185,7 +2185,7 @@ target_ulong helper_rdhwr_cc(CPUMIPSState *env)
>  {
>      if ((env->hflags & MIPS_HFLAG_CP0) ||
>          (env->CP0_HWREna & (1 << 2)))
> -        return env->CP0_Count;
> +        return (int32_t)cpu_mips_get_count(env);
>      else
>          helper_raise_exception(env, EXCP_RI);
>  
> 

Thanks for the patch, this looks correct for system mode. However, if
you try to build mips*-linux-user it will fail -- cpu_mips_get_count()
and family aren't defined in linux-user (we don't seem to care about
modifying CP0_Count).

Also, QEMU coding style requires that every indented statement is braced
(these style issues are in quite many places in existing code, but new
code should follow the correct style).

Could you fix these two issues, please?

Thanks,
Leon

Re: [Qemu-devel] [PATCH] target-mips: Fix RDHWR on CP0.Count

[Alex Smith]

On 08/09/2015 10:44, Leon Alrae wrote:
> On 04/09/15 09:21, Alex Smith wrote:
>> For RDHWR on the CP0.Count register, env->CP0_Count was being returned.
>> This value is a delta against the QEMU_CLOCK_VIRTUAL clock, not the
>> correct current value of CP0.Count. Use cpu_mips_get_count() instead.
>>
>> Signed-off-by: Alex Smith <alex.smith@imgtec.com>
>> Cc: Aurelien Jarno <aurelien@aurel32.net>
>> Cc: Leon Alrae <leon.alrae@imgtec.com>
>> ---
>>  target-mips/op_helper.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
>> index 809a061e296b..6fe00201c10d 100644
>> --- a/target-mips/op_helper.c
>> +++ b/target-mips/op_helper.c
>> @@ -2185,7 +2185,7 @@ target_ulong helper_rdhwr_cc(CPUMIPSState *env)
>>  {
>>      if ((env->hflags & MIPS_HFLAG_CP0) ||
>>          (env->CP0_HWREna & (1 << 2)))
>> -        return env->CP0_Count;
>> +        return (int32_t)cpu_mips_get_count(env);
>>      else
>>          helper_raise_exception(env, EXCP_RI);
>>  
>>
> 
> Thanks for the patch, this looks correct for system mode. However, if
> you try to build mips*-linux-user it will fail -- cpu_mips_get_count()
> and family aren't defined in linux-user (we don't seem to care about
> modifying CP0_Count).
> 
> Also, QEMU coding style requires that every indented statement is braced
> (these style issues are in quite many places in existing code, but new
> code should follow the correct style).
> 
> Could you fix these two issues, please?

Sure, will do. I'll send a new patch shortly.

Thanks,
Alex