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: Fri, 1 May 2020 19:56:48 +0100	[thread overview]
Message-ID: <CAC41xo0BMA93jv_aqzmuaB553kxM8zCZms1M89uybxyhdjxiXg@mail.gmail.com> (raw)
In-Reply-To: <CAC41xo2-knUMRVALdftzu4cNz5u5UmBf1aK=mAt9YKzvOcCjpg@mail.gmail.com>

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."

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: 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: Fri, 1 May 2020 19:56:48 +0100	[thread overview]
Message-ID: <CAC41xo0BMA93jv_aqzmuaB553kxM8zCZms1M89uybxyhdjxiXg@mail.gmail.com> (raw)
In-Reply-To: <CAC41xo2-knUMRVALdftzu4cNz5u5UmBf1aK=mAt9YKzvOcCjpg@mail.gmail.com>

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."

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-01 18:57 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 [this message]
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=CAC41xo0BMA93jv_aqzmuaB553kxM8zCZms1M89uybxyhdjxiXg@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.