From: Mark Brown <broonie@kernel.org>
To: Marc Zyngier <maz@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Zhang Lei <zhang.lei@jp.fujitsu.com>,
Andre Przywara <andre.przywara@arm.com>,
Will Deacon <will@kernel.org>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 5/7] arm64/fpsimd: Load FP state based on recorded data type
Date: Tue, 20 Sep 2022 20:02:15 +0100 [thread overview]
Message-ID: <YyoON+yTX2yYSngN@sirena.org.uk> (raw)
In-Reply-To: <87tu51kiwi.wl-maz@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 1432 bytes --]
On Tue, Sep 20, 2022 at 07:19:57PM +0100, Marc Zyngier wrote:
> Mark Brown <broonie@kernel.org> wrote:
> > Now that we are recording the type of floating point register state we
> > are saving when we save it we can use that information when we load to
> > decide which register state is required and bring the TIF_SVE state into
> > sync with the loaded register state.
> Really, this sentence makes zero sense to me. Please at least add some
> punctuation, because the only words that spring to mind here are "DOES
> NOT COMPUTE".
I'll try to come up with something...
> > + default:
> > + /*
> > + * This should never happen, we should always
> > + * record what we saved when we save. We
> > + * always at least have the memory allocated
> > + * for FPSMID registers so try that and hope
> > + * for the best.
> > + */
> > + WARN_ON_ONCE(1);
> > + clear_thread_flag(TIF_SVE);
> > + break;
> What makes it impossible for FP_STATE_TASK to reach this point? If
> that's indeed an impossible case, please document it.
That's what the "we should always record what we saved when we
saved" is doing, and the comment in the header about it not being
valid to record _TASK as a saved state. When we write the
register state to memory we must always write either FPSIMD or
SVE register values depending on which registers we saved state
for. _TASK is not a meaningful state for stored register values.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 151 bytes --]
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
next prev parent reply other threads:[~2022-09-20 19:02 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-15 22:55 [PATCH v3 0/7] arm64/sve: Clean up KVM integration and optimise syscalls Mark Brown
2022-08-15 22:55 ` [PATCH v3 1/7] KVM: arm64: Discard any SVE state when entering KVM guests Mark Brown
2022-09-20 16:44 ` Marc Zyngier
2022-09-20 20:21 ` Mark Brown
2022-09-21 17:31 ` Marc Zyngier
2022-09-22 11:44 ` Mark Brown
2022-08-15 22:55 ` [PATCH v3 2/7] arm64/fpsimd: Track the saved FPSIMD state type separately to TIF_SVE Mark Brown
2022-09-20 17:14 ` Marc Zyngier
2022-09-20 18:09 ` Mark Brown
2022-09-20 18:30 ` Marc Zyngier
2022-08-15 22:55 ` [PATCH v3 3/7] arm64/fpsimd: Have KVM explicitly say which FP registers to save Mark Brown
2022-09-20 17:52 ` Marc Zyngier
2022-09-20 18:32 ` Mark Brown
2022-09-21 17:47 ` Marc Zyngier
2022-09-22 12:18 ` Mark Brown
2022-08-15 22:55 ` [PATCH v3 4/7] arm64/fpsimd: Stop using TIF_SVE to manage register saving in KVM Mark Brown
2022-09-20 18:04 ` Marc Zyngier
2022-09-20 18:53 ` Mark Brown
2022-08-15 22:55 ` [PATCH v3 5/7] arm64/fpsimd: Load FP state based on recorded data type Mark Brown
2022-09-20 18:19 ` Marc Zyngier
2022-09-20 19:02 ` Mark Brown [this message]
2022-08-15 22:55 ` [PATCH v3 6/7] arm64/fpsimd: SME no longer requires SVE register state Mark Brown
2022-08-15 22:55 ` [PATCH v3 7/7] arm64/sve: Leave SVE enabled on syscall if we don't context switch Mark Brown
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=YyoON+yTX2yYSngN@sirena.org.uk \
--to=broonie@kernel.org \
--cc=andre.przywara@arm.com \
--cc=catalin.marinas@arm.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=will@kernel.org \
--cc=zhang.lei@jp.fujitsu.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).