All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jose Martins <josemartins90@gmail.com>
To: Alistair Francis <alistair23@gmail.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
	"open list:RISC-V" <qemu-riscv@nongnu.org>,
	"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>
Subject: Re: [PATCH 1/1] target/riscv: fix VS interrupts forwarding to HS
Date: Wed, 29 Apr 2020 17:06:50 +0100	[thread overview]
Message-ID: <CAC41xo3qeQZ+i8XoQq3j80_JDEoL2yMA__arpmE+GXyjX4c1sg@mail.gmail.com> (raw)
In-Reply-To: <CAKmqyKPDzusVqzCFwCJ+2gY0qchguhR57zHNkE-0MTeffKs_OA@mail.gmail.com>

> If the Hypervisor sets the V* interrupts why does it then want to
> receive the interrupt itself?

I don't think this is a question of whether there is a use case for it
or not (I agree with you, of the top of my head I don't see why would
you forward v* interrupts to the hypervisor). However,  from what I
can understand,  the spec allows for it. If you don't set the
corresponding bits in hideleg, v* interrupts should be forwarded to HS
(as I said, they are guaranteed not to be forwarded to m mode because
these bits must be hardwired in mideleg). Otherwise, there would be no
purpose for the hideleg register, as v* interrupts bits are the only
ones that can be written in it (am I missing something?).

> Isn't hs_sie only ever accessed if riscv_cpu_virt_enabled(env)?
> Doesn't this just set hs_sie to always be 1?

I don't understand if you don'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 <josemartins90@gmail.com>
---
 target/riscv/cpu_helper.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index d3ba9efb02..a85eadb4fb 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -41,10 +41,8 @@ static int riscv_cpu_local_irq_pending(CPURISCVState *env)

     target_ulong mstatus_mie = get_field(env->mstatus, MSTATUS_MIE);
     target_ulong mstatus_sie = get_field(env->mstatus, MSTATUS_SIE);
-    target_ulong hs_mstatus_sie = get_field(env->mstatus_hs, MSTATUS_SIE);

-    target_ulong pending = env->mip & env->mie &
-                               ~(MIP_VSSIP | MIP_VSTIP | MIP_VSEIP);
+    target_ulong pending = env->mip & env->mie;
     target_ulong vspending = (env->mip & env->mie &
                               (MIP_VSSIP | MIP_VSTIP | MIP_VSEIP));

@@ -52,11 +50,9 @@ static int riscv_cpu_local_irq_pending(CPURISCVState *env)
                           (env->priv == PRV_M && mstatus_mie);
     target_ulong sie    = env->priv < PRV_S ||
                           (env->priv == PRV_S && mstatus_sie);
-    target_ulong hs_sie = env->priv < PRV_S ||
-                          (env->priv == PRV_S && hs_mstatus_sie);

     if (riscv_cpu_virt_enabled(env)) {
-        target_ulong pending_hs_irq = pending & -hs_sie;
+        target_ulong pending_hs_irq = pending & ~env->hideleg;

         if (pending_hs_irq) {
             riscv_cpu_set_force_hs_excep(env, FORCE_HS_EXCEP);
-- 
2.17.1

Jose


WARNING: multiple messages have this Message-ID (diff)
From: Jose Martins <josemartins90@gmail.com>
To: Alistair Francis <alistair23@gmail.com>
Cc: "open list:RISC-V" <qemu-riscv@nongnu.org>,
	Alistair Francis <alistair.francis@wdc.com>,
	 "qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>
Subject: Re: [PATCH 1/1] target/riscv: fix VS interrupts forwarding to HS
Date: Wed, 29 Apr 2020 17:06:50 +0100	[thread overview]
Message-ID: <CAC41xo3qeQZ+i8XoQq3j80_JDEoL2yMA__arpmE+GXyjX4c1sg@mail.gmail.com> (raw)
In-Reply-To: <CAKmqyKPDzusVqzCFwCJ+2gY0qchguhR57zHNkE-0MTeffKs_OA@mail.gmail.com>

> If the Hypervisor sets the V* interrupts why does it then want to
> receive the interrupt itself?

I don't think this is a question of whether there is a use case for it
or not (I agree with you, of the top of my head I don't see why would
you forward v* interrupts to the hypervisor). However,  from what I
can understand,  the spec allows for it. If you don't set the
corresponding bits in hideleg, v* interrupts should be forwarded to HS
(as I said, they are guaranteed not to be forwarded to m mode because
these bits must be hardwired in mideleg). Otherwise, there would be no
purpose for the hideleg register, as v* interrupts bits are the only
ones that can be written in it (am I missing something?).

> Isn't hs_sie only ever accessed if riscv_cpu_virt_enabled(env)?
> Doesn't this just set hs_sie to always be 1?

I don't understand if you don'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 <josemartins90@gmail.com>
---
 target/riscv/cpu_helper.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index d3ba9efb02..a85eadb4fb 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -41,10 +41,8 @@ static int riscv_cpu_local_irq_pending(CPURISCVState *env)

     target_ulong mstatus_mie = get_field(env->mstatus, MSTATUS_MIE);
     target_ulong mstatus_sie = get_field(env->mstatus, MSTATUS_SIE);
-    target_ulong hs_mstatus_sie = get_field(env->mstatus_hs, MSTATUS_SIE);

-    target_ulong pending = env->mip & env->mie &
-                               ~(MIP_VSSIP | MIP_VSTIP | MIP_VSEIP);
+    target_ulong pending = env->mip & env->mie;
     target_ulong vspending = (env->mip & env->mie &
                               (MIP_VSSIP | MIP_VSTIP | MIP_VSEIP));

@@ -52,11 +50,9 @@ static int riscv_cpu_local_irq_pending(CPURISCVState *env)
                           (env->priv == PRV_M && mstatus_mie);
     target_ulong sie    = env->priv < PRV_S ||
                           (env->priv == PRV_S && mstatus_sie);
-    target_ulong hs_sie = env->priv < PRV_S ||
-                          (env->priv == PRV_S && hs_mstatus_sie);

     if (riscv_cpu_virt_enabled(env)) {
-        target_ulong pending_hs_irq = pending & -hs_sie;
+        target_ulong pending_hs_irq = pending & ~env->hideleg;

         if (pending_hs_irq) {
             riscv_cpu_set_force_hs_excep(env, FORCE_HS_EXCEP);
-- 
2.17.1

Jose


  reply	other threads:[~2020-04-29 16:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-18 18:01 [PATCH 1/1] target/riscv: fix VS interrupts forwarding to HS Jose Martins
2020-04-18 18:01 ` Jose Martins
2020-04-27 21:40 ` Alistair Francis
2020-04-27 21:40   ` Alistair Francis
2020-04-29 16:06   ` Jose Martins [this message]
2020-04-29 16:06     ` Jose Martins
2020-04-29 18:43     ` Alistair Francis
2020-04-29 18:43       ` Alistair Francis
2020-04-29 21:08       ` Jose Martins
2020-04-29 21:08         ` Jose Martins
2020-04-30 19:33         ` Alistair Francis
2020-04-30 19:33           ` Alistair Francis
2020-04-30 21:47           ` Jose Martins
2020-04-30 21:47             ` Jose Martins
2020-05-01 18:56             ` Jose Martins
2020-05-01 18:56               ` Jose Martins
2020-05-05 19:54               ` Alistair Francis
2020-05-05 19:54                 ` 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=CAC41xo3qeQZ+i8XoQq3j80_JDEoL2yMA__arpmE+GXyjX4c1sg@mail.gmail.com \
    --to=josemartins90@gmail.com \
    --cc=alistair.francis@wdc.com \
    --cc=alistair23@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    /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: link
Be 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.