From: Alistair Francis <alistair23@gmail.com>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: Alistair Francis <alistair.francis@wdc.com>,
"open list:RISC-V" <qemu-riscv@nongnu.org>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Alistair Francis <alistair.francis@opensource.wdc.com>,
Bin Meng <bmeng.cn@gmail.com>
Subject: Re: [PATCH v2 2/3] target/riscv: Implement the stval/mtval illegal instruction
Date: Wed, 29 Sep 2021 13:56:41 +1000 [thread overview]
Message-ID: <CAKmqyKMJfBqCkNrPYKZEJ-c13cn1OQ2C5AR=o1uwZefYRdCqmQ@mail.gmail.com> (raw)
In-Reply-To: <627458f0-01f1-9381-cd25-931e953031e3@linaro.org>
On Fri, Sep 24, 2021 at 10:57 PM Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 9/24/21 2:48 AM, Alistair Francis wrote:
> >> But... more specific to this case. Prior to this, was the exception handler allowed to
> >> assume anything about the contents of stval? Should the value have been zero? Would it
> >> be wrong to write to stval unconditionally? How does the guest OS know that it can rely
> >> on stval being set?
> >
> > As we didn't support writing the illegal instruction stval should be
> > zero before this patch.
>
> Ok, that didn't quite answer the question...
>
> If *wasn't* zero before this patch: we didn't write anything at all, and so keep whatever
> previous value the previous exception wrote.
>
> Is that a bug that needs fixing? Because you're still not writing anything to stval if
> !MTVAL_INST...
Yeah, that sounds like a bug then.
>
> >> I simply wonder whether it's worthwhile to add the feature and feature test.
> >
> > Do you just mean have it enabled all the time?
>
> Yes, if without this feature the value of stval was undefined.
Ok, I'll have another look at this. Thanks for pointing this out.
Alistair
>
>
> r~
WARNING: multiple messages have this Message-ID (diff)
From: Alistair Francis <alistair23@gmail.com>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: Alistair Francis <alistair.francis@opensource.wdc.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
"open list:RISC-V" <qemu-riscv@nongnu.org>,
Bin Meng <bmeng.cn@gmail.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Alistair Francis <alistair.francis@wdc.com>
Subject: Re: [PATCH v2 2/3] target/riscv: Implement the stval/mtval illegal instruction
Date: Wed, 29 Sep 2021 13:56:41 +1000 [thread overview]
Message-ID: <CAKmqyKMJfBqCkNrPYKZEJ-c13cn1OQ2C5AR=o1uwZefYRdCqmQ@mail.gmail.com> (raw)
In-Reply-To: <627458f0-01f1-9381-cd25-931e953031e3@linaro.org>
On Fri, Sep 24, 2021 at 10:57 PM Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 9/24/21 2:48 AM, Alistair Francis wrote:
> >> But... more specific to this case. Prior to this, was the exception handler allowed to
> >> assume anything about the contents of stval? Should the value have been zero? Would it
> >> be wrong to write to stval unconditionally? How does the guest OS know that it can rely
> >> on stval being set?
> >
> > As we didn't support writing the illegal instruction stval should be
> > zero before this patch.
>
> Ok, that didn't quite answer the question...
>
> If *wasn't* zero before this patch: we didn't write anything at all, and so keep whatever
> previous value the previous exception wrote.
>
> Is that a bug that needs fixing? Because you're still not writing anything to stval if
> !MTVAL_INST...
Yeah, that sounds like a bug then.
>
> >> I simply wonder whether it's worthwhile to add the feature and feature test.
> >
> > Do you just mean have it enabled all the time?
>
> Yes, if without this feature the value of stval was undefined.
Ok, I'll have another look at this. Thanks for pointing this out.
Alistair
>
>
> r~
next prev parent reply other threads:[~2021-09-29 3:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-08 4:54 [PATCH v2 0/3] RISC-V: Populate mtval and stval Alistair Francis
2021-09-08 4:54 ` [PATCH v2 1/3] target/riscv: Set the opcode in DisasContext Alistair Francis
2021-09-08 5:42 ` Bin Meng
2021-09-08 5:42 ` Bin Meng
2021-09-08 6:27 ` Richard Henderson
2021-09-08 6:27 ` Richard Henderson
2021-09-08 4:54 ` [PATCH v2 2/3] target/riscv: Implement the stval/mtval illegal instruction Alistair Francis
2021-09-08 5:53 ` Bin Meng
2021-09-08 5:53 ` Bin Meng
2021-09-08 6:48 ` Richard Henderson
2021-09-08 6:48 ` Richard Henderson
2021-09-24 6:48 ` Alistair Francis
2021-09-24 6:48 ` Alistair Francis
2021-09-24 12:57 ` Richard Henderson
2021-09-24 12:57 ` Richard Henderson
2021-09-29 3:56 ` Alistair Francis [this message]
2021-09-29 3:56 ` Alistair Francis
2021-09-08 4:54 ` [PATCH v2 3/3] target/riscv: Set mtval and stval support Alistair Francis
2021-09-08 5:55 ` Bin Meng
2021-09-08 5:55 ` Bin Meng
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='CAKmqyKMJfBqCkNrPYKZEJ-c13cn1OQ2C5AR=o1uwZefYRdCqmQ@mail.gmail.com' \
--to=alistair23@gmail.com \
--cc=alistair.francis@opensource.wdc.com \
--cc=alistair.francis@wdc.com \
--cc=bmeng.cn@gmail.com \
--cc=palmer@dabbelt.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=richard.henderson@linaro.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.