Re: [Qemu-devel] RISCV: when will the CLIC be ready?
On 2019/8/20 上午2:56, Alistair Francis wrote:
On Mon, Aug 19, 2019 at 6:44 AM liuzhiwei wrote:
On 2019/8/17 上午1:29, Alistair Francis wrote:
On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei 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.
Alistair
OK, I'd like to. As the vector extension patch has already been under
data disclosure review,
I will forward move on to this work and send the patch about two or
three weeks later.
Best Regards,
Zhiwei
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
Re: [Qemu-devel] RISCV: when will the CLIC be ready?
On Tue, Aug 20, 2019 at 3:09 AM Alistair Francis wrote:
>
> On Mon, Aug 19, 2019 at 6:44 AM liuzhiwei wrote:
> >
> >
> > On 2019/8/17 上午1:29, Alistair Francis wrote:
> > > On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei 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
Re: [Qemu-devel] RISCV: when will the CLIC be ready?
On Mon, Aug 19, 2019 at 6:44 AM liuzhiwei wrote:
>
>
> On 2019/8/17 上午1:29, Alistair Francis wrote:
> > On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei 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.
Alistair
>
> 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
> >>
Re: [Qemu-devel] RISCV: when will the CLIC be ready?
On 2019/8/17 上午1:29, Alistair Francis wrote:
On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei 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
Re: [Qemu-devel] RISCV: when will the CLIC be ready?
On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei 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 > > 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 >
[Qemu-devel] RISCV: when will the CLIC be ready?
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. 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
