[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] target-mips: fix MIPS64R6-generic configuration
From: |
Yongbok Kim |
Subject: |
Re: [Qemu-devel] [PATCH] target-mips: fix MIPS64R6-generic configuration |
Date: |
Wed, 1 Jul 2015 15:21:53 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 |
On 01/07/2015 15:06, Aurelien Jarno wrote:
> On 2015-07-01 14:57, Yongbok Kim wrote:
>> On 01/07/2015 14:48, Aurelien Jarno wrote:
>>> On 2015-06-29 10:11, Yongbok Kim wrote:
>>>> Fix core configuration for MIPS64R6-generic to make it as close as
>>>> I6400.
>>>> I6400 core has 48-bit of Virtual Address available (SEGBITS).
>>>> MIPS SIMD Architecture is available.
>>>> Rearrange order of bits to match the specification.
>>>>
>>>> Signed-off-by: Yongbok Kim <address@hidden>
>>>> ---
>>>> target-mips/mips-defs.h | 2 +-
>>>> target-mips/translate_init.c | 18 +++++++++---------
>>>> 2 files changed, 10 insertions(+), 10 deletions(-)
>>>
>>> Reviewed-by: Aurelien Jarno <address@hidden>
>>>
>>> That said given we are getting closer to the I6400 CPU model, shouldn't
>>> we try to directly model a I6400 core (even if we have to disable some
>>> features like IEEE 754-2008 FP) instead of a generic MIPS64R6 core?
>>>
>>
>> I fully agree with that but detailed specification of I6400 has not been
>> published yet, therefore for the time being we will need to use the generic
>
> Oh ok.
>
>> core name. However we could rename mips32r5-generic into P5600 with such
>> restrictions - Hardware page table walk, Virtualization, EVA.
>> What do you think?
>
> I think it's a good idea, as long as we keep the config register in sync
> with what is actually implemented.
>
I will form a patch to do that.
> That also reminds me that we should look at implementing hardware page
> table walk. That should be relatively easy to implement, and provide a
> huge performance boost (exceptions cost a lot on QEMU).
>
Actually I have implemented HTW (for MIPS32 only) but due to lack of
resources, I couldn't upstream it for 2.4. Please have a look at below commits.
https://github.com/yongbok/prpl-qemu/commit/b39e60b4039bb72ab5eccabfb75f6e6389d89bfd
https://github.com/yongbok/prpl-qemu/commit/4fd75126c1d78d84a91c659de17a5bc45efdef27
Regards,
Yongbok