From: Richard Henderson <richard.henderson@linaro.org>
To: Daniel Henrique Barboza <dbarboza@ventanamicro.com>,
Ivan Klokov <ivan.klokov@syntacore.com>,
qemu-devel@nongnu.org
Cc: qemu-riscv@nongnu.org, palmer@dabbelt.com,
alistair.francis@wdc.com, bin.meng@windriver.com,
liwei1518@gmail.com, zhiwei_liu@linux.alibaba.com
Subject: Re: [PATCH 1/1] target/riscv: Clear vstart_qe_zero flag
Date: Sat, 17 Feb 2024 09:34:54 -1000 [thread overview]
Message-ID: <72c7503b-0f43-44b8-aa82-fbafed2aac0c@linaro.org> (raw)
In-Reply-To: <3d76be6d-e3a2-4730-a54f-2893ab4ed72e@ventanamicro.com>
On 2/17/24 00:53, Daniel Henrique Barboza wrote:
> This patch is replacing mark_vs_dirty() with finalize(), that does call mark_vs_dirty() and
> set start_eq_zero = true, but it's missing the start_eq_zero update for store functions
> because of these ifs.
>
> We could just remove these ifs and finalize() all the time. To keep the existing logic
> (i.e. not set vs_dirty for writes) I would do, in this same patch:
>
>
>> if (!is_store) {
>> mark_vs_dirty(s);
>> }
>> + s->start_eq_zero = true;
>
>
> This would make these load/stores functions different from the rest, without a finalize()
> call, but given that they're already difference sine vs_dirty() is conditional I guess
> it's fine.
>
>
> What do you think?
I think it's required to have stores set dirty unconditionally, before the operation.
Consider a store that traps on the 2nd element, leaving vstart = 2, and exiting to the
main loop via exception. The exception enters the kernel page fault handler. The kernel
may need to fault in the page for the process, and in the meantime task switch.
If vs dirty is not already set, the kernel won't know to save vector state on task switch.
r~
prev parent reply other threads:[~2024-02-17 19:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-14 11:18 [PATCH 1/1] target/riscv: Clear vstart_qe_zero flag Ivan Klokov
2023-12-14 11:41 ` Daniel Henrique Barboza
2024-02-17 10:53 ` Daniel Henrique Barboza
2024-02-17 19:34 ` Richard Henderson [this message]
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=72c7503b-0f43-44b8-aa82-fbafed2aac0c@linaro.org \
--to=richard.henderson@linaro.org \
--cc=alistair.francis@wdc.com \
--cc=bin.meng@windriver.com \
--cc=dbarboza@ventanamicro.com \
--cc=ivan.klokov@syntacore.com \
--cc=liwei1518@gmail.com \
--cc=palmer@dabbelt.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=zhiwei_liu@linux.alibaba.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).