All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alistair Francis <alistair23@gmail.com>
To: Jose Martins <josemartins90@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: Tue, 5 May 2020 12:54:22 -0700	[thread overview]
Message-ID: <CAKmqyKO5nJwN_JyvZ4vMc4rcuJD3j3uPVkBZU+uB4dEyiYUDDw@mail.gmail.com> (raw)
In-Reply-To: <CAC41xo0BMA93jv_aqzmuaB553kxM8zCZms1M89uybxyhdjxiXg@mail.gmail.com>

On Fri, May 1, 2020 at 11:57 AM Jose Martins <josemartins90@gmail.com> wrote:
>
> Reached out to Andrew Waterman. This was his response:
>
> "I think the encoding of the privileged modes is a red herring.  HS is
> inherently more privileged than VS, since it controls memory
> protection and interrupt delegation for VS.
> Certainly the intent is that HS-mode interrupts are always enabled
> while executing in VS-mode.  Otherwise, badly behaved VS-mode software
> could starve HS-mode of interrupts."

Ok, so in which case the hs_sie variable should be removed.

Alistair

>
> So my assumption was correct.
>
> Jose
>
> On Thu, 30 Apr 2020 at 22:47, Jose Martins <josemartins90@gmail.com> wrote:
> >
> > > 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. I'll try to reach out to the spec
> > authors to clarify this.
> >
> > Jose


WARNING: multiple messages have this Message-ID (diff)
From: Alistair Francis <alistair23@gmail.com>
To: Jose Martins <josemartins90@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: Tue, 5 May 2020 12:54:22 -0700	[thread overview]
Message-ID: <CAKmqyKO5nJwN_JyvZ4vMc4rcuJD3j3uPVkBZU+uB4dEyiYUDDw@mail.gmail.com> (raw)
In-Reply-To: <CAC41xo0BMA93jv_aqzmuaB553kxM8zCZms1M89uybxyhdjxiXg@mail.gmail.com>

On Fri, May 1, 2020 at 11:57 AM Jose Martins <josemartins90@gmail.com> wrote:
>
> Reached out to Andrew Waterman. This was his response:
>
> "I think the encoding of the privileged modes is a red herring.  HS is
> inherently more privileged than VS, since it controls memory
> protection and interrupt delegation for VS.
> Certainly the intent is that HS-mode interrupts are always enabled
> while executing in VS-mode.  Otherwise, badly behaved VS-mode software
> could starve HS-mode of interrupts."

Ok, so in which case the hs_sie variable should be removed.

Alistair

>
> So my assumption was correct.
>
> Jose
>
> On Thu, 30 Apr 2020 at 22:47, Jose Martins <josemartins90@gmail.com> wrote:
> >
> > > 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. I'll try to reach out to the spec
> > authors to clarify this.
> >
> > Jose


  reply	other threads:[~2020-05-05 20:04 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
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 [this message]
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=CAKmqyKO5nJwN_JyvZ4vMc4rcuJD3j3uPVkBZU+uB4dEyiYUDDw@mail.gmail.com \
    --to=alistair23@gmail.com \
    --cc=alistair.francis@wdc.com \
    --cc=josemartins90@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.