Re: [Qemu-devel] [Qemu-riscv] RISCV: when will the CLIC be ready?

[Alistair Francis]

On Tue, Aug 20, 2019 at 8:38 PM liuzhiwei <address@hidden> wrote:
>
>
> On 2019/8/20 上午12:38, Chih-Min Chao wrote:
>
>
>
> On Mon, Aug 19, 2019 at 9:47 PM liuzhiwei <address@hidden> wrote:
>>
>>
>> On 2019/8/17 上午1:29, Alistair Francis wrote:
>> > On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei<address@hidden>  wrote:
>> >> Hi, Palmer
>> >>
>> >> When Michael Clark still was the maintainer of RISCV QEMU, he wrote in 
>> >> the mail list, "the CLIC interrupt controller is under testing,
>> >> and will be included in QEMU 3.1 or 3.2". It is pity that the CLIC is not 
>> >> in
>> >> included even in QEMU 4.1.0.
>> > I see that there is a CLIC branch available here:
>> > https://github.com/riscv/riscv-qemu/pull/157
>> >
>> > It looks like all of the work is in a single commit
>> > (https://github.com/riscv/riscv-qemu/pull/157/commits/206d9ac339feb9ef2c325402a00f0f45f453d019)
>> > and that most of the other commits in the PR have already made it into
>> > master.
>> >
>> > Although the CLIC commit is very large it doesn't seem impossible to
>> > manually pull out the CLIC bits and apply it onto master.
>> >
>> > Do you know the state of the CLIC model? If it's working it shouldn't
>> > be too hard to rebase the work and get the code into mainline.
>> >
>> > Alistair
>> >
>> Hi,  Alistair
>>
>> In my opinion, the CLIC code almost works.
>>
>> Last year when my workmate ported an RTOS, I once read the CLIC 
>> specification and used the CLIC model code. It worked through  all the tests 
>> after fixed two bugs. I also had sent the patch to Michael, but without 
>> response(maybe a wrong email address).
>>
>> diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
>> index 7bf6cbc..95d80ab 100644
>> --- a/target/riscv/cpu_helper.c
>> +++ b/target/riscv/cpu_helper.c
>> @@ -505,6 +505,9 @@ static target_ulong riscv_intr_pc(CPURISCVState *env,
>>       if (!(async || clic)) {
>>           return tvec & ~0b11;
>>       }
>> +    if (clic) {
>> +        cause &= 0x3ff;
>> +    }
>>
>>       /* bits [1:0] encode mode; 0 = direct, 1 = vectored, 2 >= reserved */
>>       switch (mode1) {
>> @@ -645,6 +648,9 @@ void riscv_cpu_do_interrupt(CPUState *cs)
>>           riscv_cpu_set_mode(env, PRV_M);
>>       }
>>
>> +    if (clic) {
>> +        env->exccode = 0;
>> +    }
>>       /* NOTE: it is not necessary to yield load reservations here. It is 
>> only
>>          necessary for an SC from "another hart" to cause a load reservation
>>          to be yielded. Refer to the memory consistency model section of the
>>
>> After that, the specification has updated and the code may changed. I didn't 
>> pull new code again.
>>
>> If the CLIC model may merged into the mainline, and no body maintain the 
>> code, I'd like to work on it, fixing the bugs and updating the code 
>> according to latest specification.
>>
>> Best Regards,
>> Zhiwei
>>
>> >> As we have cpus using CLIC, I have to use the out of tree qemu code in 
>> >> SIFIVE
>> >> a long time. Could you tell me when it will be upstreamed?
>> >>
>> >> Best Regards
>> >> Zhiwei
>> >>
>>
>
> Hi Zhiwei,
>
> I think what Alistair point out is the latest clic version (or 
> https://github.com/riscv/riscv-qemu/tree/riscv-qemu-3.1).  The two versions, 
> on pull request and 3.1 branch, should be similar.
>
> As far as I know, there is no concrete plan on CLIC patch in short term.
> It is good to know that the clic patch has been run with real RTOS.
> It is also great if you could update the implementation to latest spec and 
> send the patch again.
>
> chihmin
>
> Hi chihmin,
>
> Thanks for your reminding and approval. I will pull the latest clic version 
> code and send the patch about two or three weeks later.

Great! I'm glad to see more contributions!

Alistair

>
> The RTOS is Rhino,  which is the kernel of 
> AliOS-Things(https://github.com/alibaba/AliOS-Things).
>
> It is also the kernel of YOC(https://cop.c-sky.com).
>
> Best Regards
> Zhiwei