qemu-devel
[Top][All Lists]
Advanced

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

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


From: liuzhiwei
Subject: Re: [Qemu-devel] [Qemu-riscv] RISCV: when will the CLIC be ready?
Date: Wed, 21 Aug 2019 11:33:54 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1


On 2019/8/20 上午12:38, Chih-Min Chao wrote:


On Mon, Aug 19, 2019 at 9:47 PM liuzhiwei <address@hidden <mailto:address@hidden>> wrote:


    On 2019/8/17 上午1:29, Alistair Francis wrote:
    > On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei<address@hidden
    <mailto: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.

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



reply via email to

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