From: Will Deacon <will@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
linux-arm-kernel@lists.infradead.org,
Ard Biesheuvel <ardb@kernel.org>, Marc Zyngier <maz@kernel.org>
Subject: Re: [PATCH v6] arm64: smccc: Support SMCCC v1.3 SVE register saving hint
Date: Tue, 8 Jun 2021 13:15:33 +0100 [thread overview]
Message-ID: <20210608121533.GG10174@willie-the-truck> (raw)
In-Reply-To: <20210603184118.15090-1-broonie@kernel.org>
On Thu, Jun 03, 2021 at 07:41:18PM +0100, Mark Brown wrote:
> SMCCC v1.2 requires that all SVE state be preserved over SMC calls which
> introduces substantial overhead in the common case where there is no SVE
> state in the registers. To avoid this SMCCC v1.3 introduces a flag which
> allows the caller to say that there is no state that needs to be preserved
> in the registers. Make use of this flag, setting it if the SMCCC version
> indicates support for it and the TIF_ flags indicate that there is no live
> SVE state in the registers, this avoids placing any constraints on when
> SMCCC calls can be done or triggering extra saving and reloading of SVE
> register state in the kernel.
>
> This would be straightforward enough except for the rather entertaining
> inline assembly we use to do SMCCC v1.1 calls to allow us to take advantage
> of the limited number of registers it clobbers. Deal with this by having a
> function which we call immediately before issuing the SMCCC call to make
> our checks and set the flag. Using alternatives the overhead if SVE is
> supported but not detected at runtime can be reduced to a single NOP.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> Reviewed-by: Marc Zyngier <maz@kernel.org>
> ---
>
> v6:
> - Prototype __arm_smccc_sve_check add add the _arm to the name to fix
> issues with symbol versioning.
Can you elaborate on what was going wrong with symbol versioning, please?
Are we papering over another genksyms bug here?
Will
_______________________________________________
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:[~2021-06-08 12:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-03 18:41 [PATCH v6] arm64: smccc: Support SMCCC v1.3 SVE register saving hint Mark Brown
2021-06-08 12:15 ` Will Deacon [this message]
2021-06-08 12:29 ` Mark Brown
2021-06-08 13:15 ` Will Deacon
2021-06-08 13:23 ` Mark Brown
2021-06-08 13:21 ` Will Deacon
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=20210608121533.GG10174@willie-the-truck \
--to=will@kernel.org \
--cc=ardb@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=maz@kernel.org \
--cc=sudeep.holla@arm.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.