On Thu, Dec 22, 2022 at 12:23:49PM +, Marc Zyngier wrote:
> Mark Brown wrote:
> > the users to directly use the generated mask macros, writing
> >
> > #define ARM64_FEATURE_MASK(x) (x##_MASK)
> >
> > obviously looks redundant and if we look at the us
ong with improving the tooling:
Reviewed-by: Mark Brown
signature.asc
Description: PGP signature
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
st remove the users. This is a relatively
large code change but very mechanical.
No functional change.
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/sysreg.h| 3 -
arch/arm64/kvm/hyp/include/nvhe/fixed_config.h | 106 -
arch/arm64/kvm/hyp/nv
these
where the registers have already been converted, the remaining uses are in
the GIC code and will need conversions of the GIC registers.
No functional changes.
Signed-off-by: Mark Brown
---
arch/arm64/kvm/hyp/include/nvhe/fixed_config.h | 14 -
arch/arm64/kvm/hyp/nvhe/pkvm.c
once that appears.
To: Marc Zyngier
To: James Morse
To: Alexandru Elisei
To: Suzuki K Poulose
To: Oliver Upton
To: Catalin Marinas
To: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
Cc: kvm...@lists.linux.dev
Cc: kvmarm@lists.cs.columbia.edu
Cc: linux-ker...@vger.kernel.org
Signed-off-by
; Synchronization is needed before reading SVCR later in
> > fpsimd_save, or it may cause sync exception which can not be
> > handled by host.
Reviewed-by: Mark Brown
signature.asc
Description: PGP signature
___
kvmarm mailing
On Mon, Dec 19, 2022 at 03:27:17PM +, Marc Zyngier wrote:
> Mark Brown wrote:
> > fully represent everything in the spec yet. For things like the
> > registers with multiple possible views it's much more effort which
> > shouldn't get in the way of progress
On Sun, Dec 18, 2022 at 02:14:07PM +0900, Akihiko Odaki wrote:
> CCSIDR2_EL1 was added with FEAT_CCIDX.
>
> Signed-off-by: Akihiko Odaki
Reviewed-by: Mark Brown
This matches DDI0487I.a.
signature.asc
Description: PGP signature
___
kvmar
pted to spell out Unknown fully since Unkn is not such a
common abbreviation but I can see the desire to keep the name shorter
and it doesn't really matter so either way:
Reviewed-by: Mark Brown
signature.asc
Description: PGP signature
___
kvma
On Mon, Dec 19, 2022 at 02:47:25PM +, Marc Zyngier wrote:
> Since you're reviewing some of this, please have a look at v3[1],
> which outlined a limitation of the sysreg generation tool as well
> as a potential fix.
Hrm, would've been nice to be CCed on stuff for the tool :/
signature.asc
D
On Sun, Dec 11, 2022 at 02:16:58PM +0900, Akihiko Odaki wrote:
> CCSIDR2_EL1 was added with FEAT_CCIDX.
This corresponds to the definition in DDI0487I.a.
Reviewed-by: Mark Brown
signature.asc
Description: PGP signature
___
kvmarm mailing list
kvm
On Wed, Dec 07, 2022 at 10:00:17PM +0800, Zenghui Yu wrote:
> On 2022/4/19 19:22, Mark Brown wrote:
> > + /*
> > +* If SME is active then exit streaming mode. If ZA is active
> > +* then flush the SVE registers but leave userspace access to
> > +
On Tue, Dec 06, 2022 at 06:10:32PM +, Sean Christopherson wrote:
> Alternatively, we could have a dedicated selftests/kvm tree (or branch)?
> I almost suggested doing that on multiple occasions this cycle, but ultimately
> decided not to because it would effectively mean splitting series that
t as the automatic generation
> has no way to create multiple names for the same register bits. The
> meaning of the MSS field depends on other bits.
Reviewed-by: Mark Brown
> +Sysreg PMSNEVFR_EL13 0 9 9 1
> +Field63:0E
> +EndSysreg
JFTR as n
On Thu, Oct 20, 2022 at 02:51:02PM -0500, Rob Herring wrote:
> On Thu, Oct 20, 2022 at 9:33 AM Mark Brown wrote:
> > > +Field11:8EA
> > This looks like it should be described as an enum.
> 0bNot_Described
> 0b0001Ignored
> 0b0
On Wed, Oct 19, 2022 at 02:11:26PM -0500, Rob Herring wrote:
> Convert all the SPE register defines to automatic generation. No
> functional changes.
>
> New registers and fields for SPEv1.2 are added with the conversion.
>
> Some of the PMBSR MSS field defines are kept as the automatic generatio
On Wed, Sep 21, 2022 at 06:47:21PM +0100, Marc Zyngier wrote:
> Mark Brown wrote:
> > It means that using FP_STATE_TASK as a value for the fp_type
> > member of the task struck recording what type of state is
> > currently stored for the task is not valid, one of the
On Wed, Sep 21, 2022 at 06:31:28PM +0100, Marc Zyngier wrote:
> Mark Brown wrote:
> > There's no use for that hook now though.
> Care to clarify?
We don't do anything for SME even if we were to support SME with
no FP properly.
signature.asc
Desc
On Tue, Sep 20, 2022 at 05:44:01PM +0100, Marc Zyngier wrote:
> Mark Brown wrote:
> > void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu)
> > {
> > BUG_ON(!current->mm);
> > - BUG_ON(test_thread_flag(TIF_SVE));
> > +
> > + fpsimd_kvm_prepare();
&
On Tue, Sep 20, 2022 at 07:19:57PM +0100, Marc Zyngier wrote:
> Mark Brown 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 r
On Tue, Sep 20, 2022 at 07:04:24PM +0100, Marc Zyngier wrote:
> Mark Brown wrote:
> > - switch (last->to_save) {
> > - case FP_STATE_TASK:
> > - break;
> > - case FP_STATE_FPSIMD:
> > - WARN_ON_ONCE(save_sve_regs);
> > -
On Tue, Sep 20, 2022 at 06:52:59PM +0100, Marc Zyngier wrote:
> On Mon, 15 Aug 2022 23:55:25 +0100,
> Mark Brown wrote:
> > enum fp_state {
> > + FP_STATE_TASK, /* Save based on current, invalid as fp_type */
> How is that related to the FP_TYPE_TASK in the
On Tue, Sep 20, 2022 at 06:14:13PM +0100, Marc Zyngier wrote:
> Mark Brown wrote:
> > When we save the state for the floating point registers this can be done
> > in the form visible through either the FPSIMD V registers or the SVE Z and
> > P registers. At present we
, this
means that there is still some overhead for syscalls when SVE is in use
but it is much reduced.
Signed-off-by: Mark Brown
---
arch/arm64/kernel/fpsimd.c | 8 +++-
arch/arm64/kernel/syscall.c | 19 +--
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/arch
Now that we track the type of register state stored separately to
tracking what is active in the task it is valid to have FPSIMD register
state stored while in streaming mode so remove the special case handling
for SME when setting FPSIMD register state.
Signed-off-by: Mark Brown
---
arch/arm64
directly in the saved
SVCR and handled based on the information there.
Since we are not changing any of the save paths there should be no
functional change from this patch, further patches will make use of this
to optimise and clarify the code.
Signed-off-by: Mark Brown
---
arch/arm64/kernel
state, future patches will introduce
functional changes.
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/fpsimd.h| 2 +-
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/include/asm/processor.h | 6
arch/arm64/kernel/fpsimd.c | 58 ++
arch
ensure we save the correct data for it.
Signed-off-by: Mark Brown
---
arch/arm64/kernel/fpsimd.c | 22 --
arch/arm64/kvm/fpsimd.c| 3 ---
2 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index
ght be required this
patch does not actually update any of the decision making about what to
save, it merely starts tracking the new information and warns if the
requested state is not what we would otherwise have decided to save.
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/fpsimd.h
not shared with FPSIMD
untouched, keep the unconditional flush.
v2:
- Rebase onto v5.19-rc3.
- Don't warn when restoring streaming mode SVE without TIF_SVE.
Mark Brown (7):
KVM: arm64: Discard any SVE state when entering KVM guests
arm64/fpsimd: Track the saved FPSIMD state type s
.
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/fpsimd.h | 1 +
arch/arm64/kernel/fpsimd.c | 23 +++
arch/arm64/kvm/fpsimd.c | 3 ++-
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm
unwind_next_common() (which is the only common
> code here)
Reviewed-by: Mark Brown
It feels like more of the accessibility stuff *should* be sharable, but
yeah.
signature.asc
Description: PGP signature
___
kvmarm mailing list
kvmarm@lists.cs.c
On Tue, Jul 26, 2022 at 12:37:39AM -0700, Kalesh Singh wrote:
> Add brief description on how to use stacktrace/common.h to implement
> a stack unwinder.
Reviewed-by: Mark Brown
signature.asc
Description: PGP signature
___
kvmarm mailing list
t be able to translate HYP stack
> addresses to kernel addresses.
>
> Add a callback (stack_trace_translate_fp_fn) to allow specifying
> the translation function.
Reviewed-by: Mark Brown
with or without one very minor thing:
> static inline int unwind_next_common
On Wed, Jul 20, 2022 at 10:57:16PM -0700, Kalesh Singh wrote:
> Move unwind() to stacktrace/common.h, and as a result
> the kernel unwind_next() to asm/stacktrace.h. This allow
> reusing unwind() in the implementation of the nVHE HYP
> stack unwinder, later in the series.
Reviewed-by
On Wed, Jul 20, 2022 at 10:29:56AM +0100, Marc Zyngier wrote:
> Mark Brown wrote:
> > it. Marc Zyngier has previously noted publicly the current behaviour
> > being a consideration in the context of discusion of optimisation ideas
> > like this one, I was a bit surprised th
On Wed, Jul 20, 2022 at 10:40:03AM +0100, Marc Zyngier wrote:
> Mark Brown wrote:
> > Yes, someone might forget to update the state type but my experience
> > with this code is that it's a lot easier to spot "this is writing new
> > state, did it update the state t
On Wed, Jul 20, 2022 at 10:20:23AM +0100, Will Deacon wrote:
> On Tue, Jul 19, 2022 at 08:35:46PM +0100, Mark Brown wrote:
> > On Tue, Jul 19, 2022 at 06:35:37PM +0100, Catalin Marinas wrote:
> > > > The sysctl is disabled by default since it is anticipated that the risk
>
On Tue, Jul 19, 2022 at 06:35:37PM +0100, Catalin Marinas wrote:
> On Mon, Jun 20, 2022 at 01:41:58PM +0100, Mark Brown wrote:
> > The documented syscall ABI specifies that the SVE state not shared with
> > FPSIMD is undefined after a syscall. Currently we implement this by
>
On Thu, Jul 14, 2022 at 11:10:12PM -0700, Kalesh Singh wrote:
> Move common unwind_next logic to stacktrace/common.h. This allows
> reusing the code in the implementation the nVHE hypervisor stack
> unwinder, later in this series.
Reviewed-by: Mark Brown
signature.asc
Descrip
ly access per-cpu stacks from current in a non-preemptible
> * context.
Random perfectly fine but unrelated whitespace change here. Otherwise
Reviewed-by: Mark Brown
signature.asc
Description: PGP signature
___
kvmarm mailing list
kvmarm@
nst kernel code, so we
> make use of the shared header to avoid duplicated logic later in
> this series.
Reviewed-by: Mark Brown
signature.asc
Description: PGP signature
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs
On Mon, Jul 11, 2022 at 03:33:51PM +0100, Marc Zyngier wrote:
> Mark Brown wrote:
> > On Mon, Jul 11, 2022 at 10:40:50AM +0100, Marc Zyngier wrote:
> > > Mark Brown wrote:
> > > > + enum fp_state *type;
> > > For consistency: s/type/fp_type/ ?
&g
On Mon, Jul 11, 2022 at 10:40:50AM +0100, Marc Zyngier wrote:
> Mark Brown wrote:
> > + enum fp_state *type;
> For consistency: s/type/fp_type/ ?
Sure if nobody else wants a different bikeshed. It really needs a
longer name like fp_state_t or something but that had it's
hand
coded assembly which directly invokes syscalls. The new behaviour is
also what is currently implemented by qemu user mode emulation.
Signed-off-by: Mark Brown
---
arch/arm64/kernel/syscall.c | 36 +++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git
, this
means that there is still some overhead for syscalls when SVE is in use
but it is much reduced.
Signed-off-by: Mark Brown
---
arch/arm64/kernel/fpsimd.c | 8 +++-
arch/arm64/kernel/syscall.c | 19 +--
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/arch
directly in the saved
SVCR and handled based on the information there.
Since we are not changing any of the save paths there should be no
functional change from this patch, further patches will make use of this
to optimise and clarify the code.
Signed-off-by: Mark Brown
---
arch/arm64/kernel
ensure we save the correct data for it.
Signed-off-by: Mark Brown
---
arch/arm64/kernel/fpsimd.c | 22 --
arch/arm64/kvm/fpsimd.c| 3 ---
2 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index
ght be required this
patch does not actually update any of the decision making about what to
save, it merely starts tracking the new information and warns if the
requested state is not what we would otherwise have decided to save.
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/fpsimd.h
state, future patches will introduce
functional changes.
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/fpsimd.h| 2 +-
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/include/asm/processor.h | 6
arch/arm64/kernel/fpsimd.c | 57 ++
arch
.
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/fpsimd.h | 1 +
arch/arm64/kernel/fpsimd.c | 23 +++
arch/arm64/kvm/fpsimd.c | 3 ++-
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm
tighten it.
v2:
- Rebase onto v5.19-rc3.
- Don't warn when restoring streaming mode SVE without TIF_SVE.
Mark Brown (7):
KVM: arm64: Discard any SVE state when entering KVM guests
arm64/fpsimd: Track the saved FPSIMD state type separately to TIF_SVE
arm64/fpsimd: Have KVM exp
hand
coded assembly which directly invokes syscalls. The new behaviour is
also what is currently implemented by qemu user mode emulation.
Signed-off-by: Mark Brown
---
arch/arm64/kernel/syscall.c | 36 +++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git
ensure we save the correct data for it.
Signed-off-by: Mark Brown
---
arch/arm64/kernel/fpsimd.c | 22 --
arch/arm64/kvm/fpsimd.c| 3 ---
2 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index
, this
means that there is still some overhead for syscalls when SVE is in use
but it is much reduced.
Signed-off-by: Mark Brown
---
arch/arm64/kernel/fpsimd.c | 8 +++-
arch/arm64/kernel/syscall.c | 19 +--
2 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/arch
directly in the saved
SVCR and handled based on the information there.
Since we are not changing any of the save paths there should be no
functional change from this patch, further patches will make use of this
to optimise and clarify the code.
Signed-off-by: Mark Brown
---
arch/arm64/kernel
ght be required this
patch does not actually update any of the decision making about what to
save, it merely starts tracking the new information and warns if the
requested state is not what we would otherwise have decided to save.
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/fpsimd.h
state, future patches will introduce
functional changes.
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/fpsimd.h| 2 +-
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/include/asm/processor.h | 6 +++
arch/arm64/kernel/fpsimd.c | 63 +-
arch
t to tighten it.
Mark Brown (7):
KVM: arm64: Discard any SVE state when entering KVM guests
arm64/fpsimd: Track the saved FPSIMD state type separately to TIF_SVE
arm64/fpsimd: Have KVM explicitly say which FP registers to save
arm64/fpsimd: Stop using TIF_SVE to manage register saving in KVM
.
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/fpsimd.h | 1 +
arch/arm64/kernel/fpsimd.c | 23 +++
arch/arm64/kvm/fpsimd.c | 3 ++-
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm
On Mon, Jun 06, 2022 at 12:28:32PM +0100, Marc Zyngier wrote:
> Mark Brown wrote:
> > On Sat, May 28, 2022 at 12:38:11PM +0100, Marc Zyngier wrote:
> > > We probably never saw the issue because no VMM uses SVE, but
> > > that's still pretty bad. Unconditionally
On Mon, Jun 06, 2022 at 09:41:52AM +0100, Marc Zyngier wrote:
> Mark Brown wrote:
> > On Sat, May 28, 2022 at 12:38:14PM +0100, Marc Zyngier wrote:
> > > - FP_STATE_CLEAN
> > > - FP_STATE_HOST_DIRTY
> > > - FP_STATE_GUEST_DIRTY
> > I had to think a bit
N
> - FP_STATE_HOST_DIRTY
> - FP_STATE_GUEST_DIRTY
I had to think a bit more than I liked about the _DIRTY in the
names of the host and guest flags, but that's really just
bikeshedding and not a meaningful issue.
Reviewed-by: Mark Brown
signature.asc
Description: PGP signature
__
r not by updating the rest of the FP flags.
Reviewed-by: Mark Brown
signature.asc
Description: PGP signature
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
On Sat, May 28, 2022 at 12:38:12PM +0100, Marc Zyngier wrote:
> On each vcpu load, we set the KVM_ARM64_HOST_SME_ENABLED
> flag if SVE is enabled for EL0 on the host. This is used to
> restore the correct state on vpcu put.
s/SVE/SME/
but otherwise
Reviwed-by: Mark Brown
sign
lag. Once
> set, it will stick until the vcpu is destroyed, which has the
> potential to spuriously enable SVE for userspace.
Oh dear.
Reviewed-by: Mark Brown
> We probably never saw the issue because no VMM uses SVE, but
> that's still pretty bad. Unconditionally clearing the f
STACK_TYPES
> };
I don't immediately see a problem with it but I'm curious as to why
STACK_TYPE_UNKNOWN got moved to the end of the list here? It does mean
that zeroed memory will default to STACK_TYPE_TASK but we're not
actually relying on that. Otherwise
Reviwe
On Mon, May 02, 2022 at 12:12:01PM -0700, Kalesh Singh wrote:
> Factor out the stack unwinding logic common to both the host kernel and
> the nVHE hypersivor into __unwind_next(). This allows for reuse in the
> nVHE hypervisor stack unwinding (later in this series).
Reviewed-by: M
On Tue, May 03, 2022 at 06:23:40PM -0400, Qian Cai wrote:
> On Tue, Apr 19, 2022 at 12:22:08PM +0100, Mark Brown wrote:
> > This series provides initial support for the ARMv9 Scalable Matrix
> > Extension (SME). SME takes the approach used for vectors in SVE and
> > ex
2.056417] kvm [380]: end of nVHE HYP call trace
This will be really helpful!
Reviewed-by: Mark Brown
signature.asc
Description: PGP signature
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
On Wed, Apr 27, 2022 at 11:46:56AM -0700, Kalesh Singh wrote:
> Recompile stack unwinding code for use with the nVHE hypervisor. This is
> a preparatory patch that will allow reusing most of the kernel unwinding
> logic in the nVHE hypervisor.
This is substantially more than just the build change
On Wed, Apr 27, 2022 at 05:08:00PM -0400, Qian Cai wrote:
> On Wed, Apr 27, 2022 at 06:14:31PM +0100, Mark Brown wrote:
> > Can you try with
> >https://lore.kernel.org/r/20220427130828.162615-1-broo...@kernel.org
> > please?
> Yes, it works fine so far.
Gr
On Wed, Apr 27, 2022 at 01:08:58PM -0400, Qian Cai wrote:
> On Tue, Apr 19, 2022 at 12:22:08PM +0100, Mark Brown wrote:
> > but not SVE, SME is an ARMv9 feature and SVE is mandatory for ARMv9.
> > The code attempts to handle any such systems that are encountered but
> > th
On Wed, Apr 27, 2022 at 12:14:32AM +0200, Marek Szyprowski wrote:
> This patchset landed in linux next-20220426. By default SME is enabled
> and it breaks CPU hot-plug on all my arm64 test systems. Bisect points
> this patch, because it finally enables this feature. Here is a report
> from QEMU
sure that ZA is still enabled and it looks like the data got copied.
Signed-off-by: Mark Brown
---
tools/testing/selftests/arm64/fp/.gitignore | 1 +
tools/testing/selftests/arm64/fp/Makefile | 9 +-
.../testing/selftests/arm64/fp/za-fork-asm.S | 61 +++
tools/testing/selftests/a
store instructions
will handle the vector length for us. We log if the system supports FA64 and
only try to set FFR in streaming mode if it does.
Signed-off-by: Mark Brown
Reviewed-by: Shuah Khan
Acked-by: Catalin Marinas
---
.../selftests/arm64/abi/syscall-abi-asm.S | 79 ++-
.../testing/self
validate that both the vector size and data are being read
and written as expected when the process runs.
Signed-off-by: Mark Brown
Reviewed-by: Shuah Khan
Acked-by: Catalin Marinas
---
tools/testing/selftests/arm64/fp/.gitignore | 1 +
tools/testing/selftests/arm64/fp/Makefile| 3 +-
tools
.
- Lack of support for changing vector length.
- Presence and size of register state for streaming SVE and ZA.
As with the SVE tests we do not yet have any validation of register
contents.
Signed-off-by: Mark Brown
Reviewed-by: Shuah Khan
Acked-by: Catalin Marinas
---
.../testing/selftests
regsets.
Signed-off-by: Mark Brown
Reviewed-by: Shuah Khan
Acked-by: Catalin Marinas
---
tools/testing/selftests/arm64/fp/sve-ptrace.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/tools/testing/selftests/arm64/fp/sve-ptrace.c
b/tools/testing/selftests/arm64/fp/sve-ptrace.c
ually assemble the SME instructions since at
present no released toolchain has SME support integrated.
Signed-off-by: Mark Brown
Reviewed-by: Shuah Khan
Acked-by: Catalin Marinas
---
tools/testing/selftests/arm64/fp/.gitignore | 1 +
tools/testing/selftests/arm64/fp/Makefile | 3 +
tools/te
As part of the generic code for signal handling test cases we parse all
signal frames to make sure they have at least the basic form we expect
and that there are no unexpected frames present in the signal context.
Add coverage of the ZA signal frame to this code.
Signed-off-by: Mark Brown
n for
controlling the few small differences needed:
- Enter streaming mode immediately on starting the program.
- In streaming mode FFR is removed so skip reading and writing FFR.
Signed-off-by: Mark Brown
Reviewed-by: Shuah Khan
Acked-by: Catalin Marinas
---
tools/testing/selftests/arm64/fp/.giti
g hwcap
support to nolibc seems like disproportionate effort and didn't feel
entirely idiomatic for what nolibc is trying to do.
Signed-off-by: Mark Brown
Reviewed-by: Shuah Khan
Acked-by: Catalin Marinas
---
tools/testing/selftests/arm64/abi/.gitignore | 1 +
tools/testing/selftest
Provide RDVL helpers for SME and extend the main vector configuration tests
to cover SME.
Signed-off-by: Mark Brown
Reviewed-by: Shuah Khan
Acked-by: Catalin Marinas
---
tools/testing/selftests/arm64/fp/.gitignore | 1 +
tools/testing/selftests/arm64/fp/Makefile | 3 ++-
tools/testing
The Scalable Matrix Extenions (SME) introduces additional register state
with configurable vector lengths, similar to SVE but configured separately.
Extend vlset to support configuring this state with a --sme or -s command
line option.
Signed-off-by: Mark Brown
Reviewed-by: Shuah Khan
Acked-by
As for the kernel so that we don't have ambitious toolchain requirements
to build the tests manually encode some of the SVE instructions.
Signed-off-by: Mark Brown
Reviewed-by: Shuah Khan
Acked-by: Catalin Marinas
---
tools/testing/selftests/arm64/fp/sme-inst.h | 51 +++
with normal SVE so depend on SVE.
Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
---
arch/arm64/Kconfig | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 57c4c995965f..0897984918e8 100644
--- a/arch/arm64/Kconfig
+++ b/arch/
ms with SME and even there only if streaming mode or ZA are enabled.
Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
---
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/kvm/fpsimd.c | 36 +++
2 files changed, 37 insertions(+)
diff --git a/arch/ar
ement callbacks, along with SCTLR_EL2.EnTPIDR2. There is no
existing dynamic management of SCTLR_EL2.
For nVHE manage TSM in activate_traps() along with the fine grained
traps for TPIDR2 and SMPRI. There is no existing dynamic management of
fine grained traps.
Signed-off-by: Mark Brown
Reviewed-by: Ca
runtime services, the
specification is not yet finalised so this may need updating if that
changes.
Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
---
arch/arm64/kernel/fpsimd.c | 48 +-
1 file changed, 42 insertions(+), 6 deletions(-)
diff --git a/arch
mask out the SME bitfield in SYS_ID_AA64PFR1.
Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
---
arch/arm64/kvm/sys_regs.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 7b45c040cc27..689e53dd4cb1
idle and after flushing the state a reload is always required anyway.
Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
---
arch/arm64/kernel/fpsimd.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 94f06e9d37cf
-by: Mark Brown
Reviewed-by: Catalin Marinas
---
arch/arm64/include/uapi/asm/ptrace.h | 56 +++
arch/arm64/kernel/ptrace.c | 144 +++
include/uapi/linux/elf.h | 1 +
3 files changed, 201 insertions(+)
diff --git a/arch/arm64/include/uapi/asm
SVE registers, though
users can provide no register data as an alternative mechanism for doing
so.
Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
---
arch/arm64/include/asm/fpsimd.h | 1 +
arch/arm64/include/uapi/asm/ptrace.h | 13 +-
arch/arm64/kernel/fpsimd.c | 31
in the endinanness independent format used for vectors.
As with SVE we do not allow changes in the vector length during signal
return but we do allow ZA to be enabled or disabled.
Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
---
arch/arm64/include/uapi/asm/sigcontext.h | 41
identify a
case that is clearly better than any other - they all have cases where
they could cause unexpected register corruption or faults.
Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
---
arch/arm64/include/asm/processor.h | 8 +
arch/arm64/include/uapi/asm/sigcontext.h | 16
The ABI requires that streaming mode and ZA are disabled when invoking
signal handlers, do this in setup_return() when we prepare the task state
for the signal handler.
Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
---
arch/arm64/kernel/signal.c | 7 +++
1 file changed, 7
through to normal handling of SVE.
Signed-off-by: Mark Brown
---
arch/arm64/include/asm/esr.h | 1 +
arch/arm64/include/asm/exception.h | 1 +
arch/arm64/include/asm/fpsimd.h| 39 +++
arch/arm64/kernel/entry-common.c | 11 ++
arch/arm64/kernel/fpsimd.c | 167
issues in shared SMCU implementations.
Since ZA is architecturally guaranteed to be zeroed when enabled we do not
need to explicitly zero ZA, either we will be restoring from a saved copy
or trapping on first use of SME so we know that ZA must be disabled.
Signed-off-by: Mark Brown
Reviewed-by
precedence.
This does not handle use of streaming SVE state with KVM, ptrace or
signals. This will be updated in further patches.
Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
---
arch/arm64/include/asm/fpsimd.h | 22 +-
arch/arm64/include/asm/fpsimdmacros.h | 11 +++
arch
1 - 100 of 455 matches
Mail list logo