This patch series fixes the forwarding of VS-level execptions to HS-mode and
removes unecessary code previously used for the routing of exceptions to
HS-mode.
Jose Martins (2):
target/riscv: fix VS interrupts forwarding to HS
target/riscv: remove force HS exception
target/riscv/cpu.h
exceptions, specifically, guest page faults which must be
hardwired to zero hedeleg. As such the hs_force_except mechanism can be
removed.
Signed-off-by: Jose Martins
---
target/riscv/cpu.h| 2 --
target/riscv/cpu_bits.h | 6 --
target/riscv/cpu_helper.c | 26 +--
e
appropriate privilege level in riscv_cpu_do_interrupt.
Signed-off-by: Jose Martins
---
target/riscv/cpu_helper.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 968cb8046f..55db004fea 10
> From your last response I thought you sent a different series that
> replaces this patch. If that's not the case do you mind sending this
> patch again?
I already sent the patch series here:
https://lists.gnu.org/archive/html/qemu-devel/2021-06/msg00553.html. I
got confused, I should have raised
Hello Zhiwei and Alistair,
I noticed this patch did not make it upstream, contrarily to a couple
other patches I submitted around the same time. Is there something
else needed from my side to push this forward?
Best,
José
On Wed, 2 Jun 2021 at 20:14, Jose Martins wrote:
>
> Hello Zhiw
> > +static const target_ulong vs_delegable_excps = delegable_excps &
> > +~((1ULL << (RISCV_EXCP_S_ECALL)) |
>
> > +(1ULL << (RISCV_EXCP_VS_ECALL)) |
> > +(1ULL << (RISCV_EXCP_M_ECALL)) |
>
> These two are both read only 0, shouldn't they not be included in this list?
>
> > static int
21 at 01:36, LIU Zhiwei wrote:
>
>
> On 5/28/21 6:34 AM, Alistair Francis wrote:
> > On Sun, May 23, 2021 at 1:45 AM Jose Martins
> > wrote:
> >> VS interrupts (2, 6, 10) were not correctly forwarded to hs-mode when
> >> not delegated in hideleg (which was
e
appropriate privilege level in riscv_cpu_do_interrupt.
Signed-off-by: Jose Martins
---
target/riscv/cpu_helper.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 21c54ef561..592d4642be 10
exceptions, specifically, guest page faults which must be
hardwired to zero hedeleg. As such the hs_force_except mechanism can be
removed.
Signed-off-by: Jose Martins
---
target/riscv/cpu.h| 2 --
target/riscv/cpu_bits.h | 6 --
target/riscv/cpu_helper.c | 26 +--
This patch series fixes the forwarding of VS-level execptions to HS-mode and
removes unecessary code previously used for the routing of exceptions to
HS-mode.
Jose Martins (2):
target/riscv: fix VS interrupts forwarding to HS
target/riscv: remove force HS exception
target/riscv/cpu.h
Hello Zhiwei, thank you for reviewing the patch.
I'll split the patch in a series as you suggest. But first can you
help me understand what the problems are with
riscv_cpu_local_irq_pending?
> I think there are two errors in riscv_cpu_local_irq_pending.
>
> 1) VS interrupts can't be forwarded to
> 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 shoul
The specification mandates for certain bits to be hardwired in the
hypervisor delegation registers. This was not being enforced.
Signed-off-by: Jose Martins
---
target/riscv/csr.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/target/riscv/csr.c b/target
sm can be removed.
Signed-off-by: Jose Martins
---
This version of the patch also removes the uneeded hs_force_except
functions, variables and macro.
target/riscv/cpu.h| 2 --
target/riscv/cpu_bits.h | 6 -
target/riscv/cpu_helper.c | 54 +++
3 f
scv_cpu_do_interrupt. Also, these
interrupts never target m-mode, which is guaranteed by the hardwiring
of the corresponding bits in mideleg.
Signed-off-by: Jose Martins
---
Alistair, I sent the previous version of this patch a year ago (!).
After our brief exchange on wether
instruction exception should be raised when a wfi is executed from
virtual-user or virtual-supervisor and hstatus.vtw is set.
Signed-off-by: Jose Martins
---
Alistair, I hope you've agreed with my argumentis for the previous version
of the patch. As promised, I submit this version which takes
> > -if ((env->priv == PRV_S &&
> > -get_field(env->mstatus, MSTATUS_TW)) ||
> > -riscv_cpu_virt_enabled(env)) {
> > +if ((!riscv_cpu_virt_enabled(env) && env->priv == PRV_U) ||
>
> > +(env->priv == PRV_S && get_field(env->mstatus, MSTATUS_TW))) {
>
> Shouldn't we ch
virtual-supervisor and hstatus.vtw is set.
Signed-off-by: Jose Martins
---
target/riscv/cpu_bits.h | 1 +
target/riscv/op_helper.c | 8 +---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/target/riscv/cpu_bits.h b/target/riscv/cpu_bits.h
index 24b24c69c5..ed8b97c788 100644
abled
while executing in VS-mode. Otherwise, badly behaved VS-mode software
could starve HS-mode of interrupts."
So my assumption was correct.
Jose
On Thu, 30 Apr 2020 at 22:47, Jose Martins wrote:
>
> > I'm not sure HS is a higher privilege mode.
> >
> > HS i
20 at 22:36, Alistair Francis wrote:
>
> On Thu, Apr 30, 2020 at 12:45 PM Alistair Francis
> wrote:
> >
> > On Fri, Apr 24, 2020 at 8:10 AM Jose Martins
> > wrote:
> > >
> > > The spec states that on sv39x4 guest physical "address bits 63
irst stage except with the 2-bit extension, effectively creating
the same kind of "hole" in the guest's physical address space. I believe
the following patch fixes this issue:
Signed-off-by: Jose Martins
---
target/riscv/cpu_helper.c | 20 +---
1 file changed, 13 i
> I'm not sure HS is a higher privilege mode.
>
> HS is privilege encoding 1, which is the same as VS (VU is obviously lower).
I just checked the spec and it doesn't actually, explicitly state that
HS is a higher-privilege mode than VS. I thought this was something
implicit, but you might be right
> Your change just made it true for whenever virtulisation is enabled
> (in which case we don't need it).
This is exactly my point. As I said in the commit message, the spec
clearly tells us that "Interrupts for higher-privilege modes, y>x, are
always globally enabled regardless of the setting of
n't agree that hs_sie should be always set
when riscv_cpu_virt_enabled(env), or if you agree with it and don't
see the need for the hs_sie variable at all. If it is the latter, I
agree with you. So the patch would become:
Signed-off-by: Jose Martins
---
target/riscv/cpu_helper.c | 8 ++
irst stage except with the 2-bit extension,
effectively creating the same kind of "hole" in the guest's physical
address space. I believe the following patch fixes this issue:
Signed-off-by: Jose Martins
---
target/riscv/cpu_helper.c | 20 +---
1 file changed, 13 i
nterrupts are delegated in hideleg, there is still the
need to check it when calculating pending_hs_irq, otherwise, we're
still "forcing an hs except" when the interrupt should be forwarded to
vs. I believe the following patch will fix this issue:
Signed-off-by: Jose Martins
---
t
interrupts. In case if hypervisor has
> delegated S mode interrupts then we should not decrement cause for those
> interrupts.
>
> Regards,
> Rajnesh
>
>
> On Sun, Feb 23, 2020 at 7:41 PM Jose Martins wrote:
>>
>> Hello rajnesh,
>>
>> I had already subm
Hello rajnesh,
I had already submitted almost this exact patch a few weeks ago.
Jose
On Sun, 23 Feb 2020 at 13:51, wrote:
>
> From: Rajnesh Kanwal
>
> Currently riscv_cpu_local_irq_pending is used to find out pending
> interrupt and VS mode interrupts are being shifted to represent
> S mode in
28 matches
Mail list logo
