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

[Bin Meng]

On Tue, Aug 20, 2019 at 3:09 AM Alistair Francis <address@hidden> wrote:
>
> On Mon, Aug 19, 2019 at 6:44 AM 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.
>
> Yes please! We will be happy to merge it!
>
> If you would like to it would be great if you could update the code,
> fix the bugs and then send patches to this list.
>

Is the spec here?
https://github.com/sifive/clic-spec/blob/master/clic.adoc

Which silicon is going to have this CLIC?

Regards,
Bin