From: Mark Brown <broonie@kernel.org>
To: Dave Martin <Dave.Martin@arm.com>
Cc: Julien Grall <julien@xen.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Zhang Lei <zhang.lei@jp.fujitsu.com>,
Julien Grall <julien.grall@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Daniel Kiss <Daniel.Kiss@arm.com>
Subject: Re: [PATCH v5 1/2] arm64/sve: Don't disable SVE on syscalls return
Date: Mon, 16 Nov 2020 19:45:51 +0000 [thread overview]
Message-ID: <20201116194551.GG4739@sirena.org.uk> (raw)
In-Reply-To: <20201116175938.GA6882@arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 1145 bytes --]
On Mon, Nov 16, 2020 at 05:59:39PM +0000, Dave Martin wrote:
> So far as I can see, TIF_SVE_NEEDS_FLUSH is a special state in which SVE
> is half-enabled and the SVE regs half-loaded, so it's not an orthogonal
> flag, but a distinct state that sits between the others.
> In this state the regs are neither fully saved nor fully loaded, and we
> haven't committed to either enabling or disabling SVE for userspace.
> It's an intermediate state which we can choose our path out of based on
> policy or performance concerns.
When I say orthogonal I mean to TIF_SVE only - to me that's essentially
unrelated while we're in the kernel. It's true that we'll have to
decide if we want to transition on return to userspace but for the time
we're in the kernel it doesn't need to interact and we don't need to pay
attention to TIF_SVE when we're returning.
TIF_FOREIGN_FPSTATE is more tied up, it's definitely can't be thought of
as orthogonal. I think of that more like what Catalin was suggesting
where it's a flag about where the data is stored rather than about the
state we want to go into, which I found makes it fairly easy to reason
about.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-11-16 19:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-06 19:35 [PATCH v5 0/2] arm64/sve: First steps towards optimizing syscalls Mark Brown
2020-11-06 19:35 ` [PATCH v5 1/2] arm64/sve: Don't disable SVE on syscalls return Mark Brown
2020-11-13 18:48 ` Catalin Marinas
2020-11-13 20:13 ` Mark Brown
2020-11-16 17:59 ` Dave Martin
2020-11-16 19:45 ` Mark Brown [this message]
2020-11-17 18:16 ` Dave Martin
2020-11-17 23:03 ` Mark Brown
2020-11-18 12:51 ` Dave Martin
2020-11-18 17:52 ` Mark Brown
2020-11-19 18:27 ` Dave Martin
2020-11-19 19:02 ` Mark Brown
2020-11-06 19:35 ` [PATCH v5 2/2] arm64/sve: Rework SVE trap access to use TIF_SVE_NEEDS_FLUSH 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=20201116194551.GG4739@sirena.org.uk \
--to=broonie@kernel.org \
--cc=Daniel.Kiss@arm.com \
--cc=Dave.Martin@arm.com \
--cc=catalin.marinas@arm.com \
--cc=julien.grall@arm.com \
--cc=julien@xen.org \
--cc=linux-arm-kernel@lists.infradead.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 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.