[Top][All Lists]

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

Re: [PATCH] target/riscv: hardwire bits in hideleg and hedeleg

From: LIU Zhiwei
Subject: Re: [PATCH] target/riscv: hardwire bits in hideleg and hedeleg
Date: Fri, 28 May 2021 09:56:14 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

On 5/26/21 1:50 AM, Jose Martins wrote:
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?

Hi Jose,

Sorry I missed this mail.

Sounds good. Just keep it.

I didn't find that the RISCV_EXCP_VS_ECALL should be read-only 0 from the 
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
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.
That's will be great.

However, as hedeleg is WARL, you had better reserve the other fields like 

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.

That's the current way to implement medeleg in QEMU. I just copy the code.

In my opinion, WARL means:

1) For writable fields with WARL, any illegal written value will be discarded.

2) For reserved fields with WARL,  any written value will be discarded and it should always keep hardwired value.

I agree with your opinion. We can just use bitwise-and for medeleg.

Best Regards,


reply via email to

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