qemu-riscv.nongnu.org archive mirror
 help / color / mirror / Atom feed
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~


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