From: Jose Martins <josemartins90@gmail.com> To: LIU Zhiwei <zhiwei_liu@c-sky.com> Cc: "open list:RISC-V TCG CPUs" <qemu-riscv@nongnu.org>, Sagar Karandikar <sagark@eecs.berkeley.edu>, Bastian Koppelmann <kbastian@mail.uni-paderborn.de>, "qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>, Alistair Francis <Alistair.Francis@wdc.com>, Palmer Dabbelt <palmer@dabbelt.com> Subject: Re: [PATCH] target/riscv: hardwire bits in hideleg and hedeleg Date: Tue, 25 May 2021 18:50:50 +0100 [thread overview] Message-ID: <CAC41xo2v7kU92+MkZfB7f_86X58k8R5Ft=2vSO3OORT2OJ-Exw@mail.gmail.com> (raw) In-Reply-To: <434d8825-8bd6-5344-aea2-e176fad6183e@c-sky.com> > We can use it directly if only one macro VS_MODE_INTERRUPTS. I wrote it like this to be more coherent with what was already there which also makes it more readable. Furthermore, the compiler will just probably optimize the variable away, right? > I didn't find that the RISCV_EXCP_VS_ECALL should be read-only 0 from the specification. You are right. I had doubts about this also. The table that defines it in the spec is missing this bit. I raised an issue on the spec repo (https://github.com/riscv/riscv-isa-manual/issues/649). But in my opinion, it wouldn't really make sense to allow this exception to be delegated. What do you think? Is there any use case for this to be allowed? Maybe we'll need a clarification from the spec to reach a final decision. > However, as hedeleg is WARL, you had better reserve the other fields like medeleg: > > env->medeleg = (env->medeleg & ~delegable_excps) | (val & delegable_excps); Isn't the patch's implementation of hedeleg/hideleg providing a WARL behavior already? I don't think we need this preservation behavior since in the case of hideleg/hedeleg there can only be 0-wired bits. I believe this won't change. For hedeleg the spec states that "Each bit of hedeleg shall be either writable or hardwired to zero". For hideleg: "Among bits 15:0 of hideleg, only bits 10, 6, and 2 (corresponding to the standard VS-level interrupts) shall be writable, and the others shall be hardwired to zero." > I really don't understand why medeleg codes this way. Is there anyone can give a better explanation? I don't know if I fully understood your question, but I don't get why you would need to preserve non-delegable bits in medeleg in this way, even to keep WARL behavior. Again, the specification only allows medeleg bits to be hardwired to zero: "An implementation shall not hardwire any bits of medeleg to one, i.e., any synchronous trap that can be delegated must support not being delegated.", so a bitwise-and should suffice. José
WARNING: multiple messages have this Message-ID (diff)
From: Jose Martins <josemartins90@gmail.com> To: LIU Zhiwei <zhiwei_liu@c-sky.com> Cc: "qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>, "open list:RISC-V TCG CPUs" <qemu-riscv@nongnu.org>, Sagar Karandikar <sagark@eecs.berkeley.edu>, Bastian Koppelmann <kbastian@mail.uni-paderborn.de>, Alistair Francis <Alistair.Francis@wdc.com>, Palmer Dabbelt <palmer@dabbelt.com> Subject: Re: [PATCH] target/riscv: hardwire bits in hideleg and hedeleg Date: Tue, 25 May 2021 18:50:50 +0100 [thread overview] Message-ID: <CAC41xo2v7kU92+MkZfB7f_86X58k8R5Ft=2vSO3OORT2OJ-Exw@mail.gmail.com> (raw) In-Reply-To: <434d8825-8bd6-5344-aea2-e176fad6183e@c-sky.com> > We can use it directly if only one macro VS_MODE_INTERRUPTS. I wrote it like this to be more coherent with what was already there which also makes it more readable. Furthermore, the compiler will just probably optimize the variable away, right? > I didn't find that the RISCV_EXCP_VS_ECALL should be read-only 0 from the specification. You are right. I had doubts about this also. The table that defines it in the spec is missing this bit. I raised an issue on the spec repo (https://github.com/riscv/riscv-isa-manual/issues/649). But in my opinion, it wouldn't really make sense to allow this exception to be delegated. What do you think? Is there any use case for this to be allowed? Maybe we'll need a clarification from the spec to reach a final decision. > However, as hedeleg is WARL, you had better reserve the other fields like medeleg: > > env->medeleg = (env->medeleg & ~delegable_excps) | (val & delegable_excps); Isn't the patch's implementation of hedeleg/hideleg providing a WARL behavior already? I don't think we need this preservation behavior since in the case of hideleg/hedeleg there can only be 0-wired bits. I believe this won't change. For hedeleg the spec states that "Each bit of hedeleg shall be either writable or hardwired to zero". For hideleg: "Among bits 15:0 of hideleg, only bits 10, 6, and 2 (corresponding to the standard VS-level interrupts) shall be writable, and the others shall be hardwired to zero." > I really don't understand why medeleg codes this way. Is there anyone can give a better explanation? I don't know if I fully understood your question, but I don't get why you would need to preserve non-delegable bits in medeleg in this way, even to keep WARL behavior. Again, the specification only allows medeleg bits to be hardwired to zero: "An implementation shall not hardwire any bits of medeleg to one, i.e., any synchronous trap that can be delegated must support not being delegated.", so a bitwise-and should suffice. José
next prev parent reply other threads:[~2021-05-25 17:51 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-22 15:59 [PATCH] target/riscv: hardwire bits in hideleg and hedeleg Jose Martins 2021-05-22 15:59 ` Jose Martins 2021-05-25 7:22 ` LIU Zhiwei 2021-05-25 7:22 ` LIU Zhiwei 2021-05-25 17:50 ` Jose Martins [this message] 2021-05-25 17:50 ` Jose Martins 2021-05-28 1:56 ` LIU Zhiwei 2021-05-28 1:56 ` LIU Zhiwei 2021-05-28 2:00 ` LIU Zhiwei 2021-05-28 2:00 ` LIU Zhiwei 2021-06-10 23:12 ` Alistair Francis 2021-06-10 23:12 ` Alistair Francis 2021-06-24 13:48 ` Jose Martins 2021-06-24 13:48 ` Jose Martins 2021-07-08 4:45 ` Alistair Francis 2021-07-08 4:45 ` Alistair Francis
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAC41xo2v7kU92+MkZfB7f_86X58k8R5Ft=2vSO3OORT2OJ-Exw@mail.gmail.com' \ --to=josemartins90@gmail.com \ --cc=Alistair.Francis@wdc.com \ --cc=kbastian@mail.uni-paderborn.de \ --cc=palmer@dabbelt.com \ --cc=qemu-devel@nongnu.org \ --cc=qemu-riscv@nongnu.org \ --cc=sagark@eecs.berkeley.edu \ --cc=zhiwei_liu@c-sky.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.