On Thu, 02 Jun 2022 21:06:42 +0100,
Eric Auger wrote:
>
> Hi Marc,
> On 6/2/22 10:30, Marc Zyngier wrote:
> > Now that GICv2 has a proper userspace accessor for the pending state,
> > switch GICv3 over to it, dropping the local version.
> >
> > Signed-off-by: Marc Zyngier
> > ---
> >
On Sat, 28 May 2022 12:38:10 +0100, Marc Zyngier wrote:
> While working on pKVM, it slowly became apparent that dealing with the
> flags was a pain, as they serve multiple purposes:
>
> - some flags are purely a configuration artefact,
>
> - some are an input from the host kernel to the world
This patch series attempts to clarify the tracking of which set of
floating point registers we save on systems supporting SVE, particularly
with reference to KVM, and then uses the results of this clarification
to improve the performance of simple syscalls where we return directly
to userspace in
Since 8383741ab2e773a99 (KVM: arm64: Get rid of host SVE tracking/saving)
KVM has not tracked the host SVE state, relying on the fact that we
currently disable SVE whenever we perform a syscall. This may not be true
in future since performance optimisation may result in us keeping SVE
enabled in
On Thu, 2 Jun 2022 10:48:05 +0800, sunliming wrote:
> Fix the inconsistent indenting in function flush_context.
>
> Fix the following smatch warnings:
>
> arch/arm64/kvm/vmid.c:62 flush_context() warn: inconsistent indenting
Applied to fixes, thanks!
[1/1] KVM: arm64: fix the inconsistent
Now that GICv2 has a proper userspace accessor for the pending state,
switch GICv3 over to it, dropping the local version, moving over the
specific behaviours that CGIv3 requires (such as the distinction
between pending latch and line level which were never enforced
with GICv2).
We also gain
A recurrent bug in the KVM/arm64 code base consists in trying to
access the timer pending state outside of the vcpu context, which
makes zero sense (the pending state only exists when the vcpu
is loaded).
In order to avoid more embarassing crashes and catch the offenders
red-handed, add a warning
Since 5bfa685e62e9 ("KVM: arm64: vgic: Read HW interrupt pending state
from the HW"), we're able to source the pending bit for an interrupt
that is stored either on the physical distributor or on a device.
However, this state is only available when the vcpu is loaded,
and is not intended to be
This is a followup from [1], which aims at fixing userspace access to
interrupt pending state for HW interrupts.
* From v1 [1]:
- Keep some of the GICv3-specifics around to avoid regressing the
line vs latch distinction (Eric).
[1]
The syscall ABI says that the SVE register state not shared with FPSIMD
may not be preserved on syscall, and this is the only mechanism we have
in the ABI to stop tracking the extra SVE state for a process. Currently
we do this unconditionally by means of disabling SVE for the process on
syscall,
Now that we are explicitly telling the host FP code which register state
it needs to save we can remove the manipulation of TIF_SVE from the KVM
code, simplifying it and allowing us to optimise our handling of normal
tasks. Remove the manipulation of TIF_SVE from KVM and instead rely on
to_save to
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 track which format is currently used based on
TIF_SVE and the SME streaming mode state but particularly in the SVE case
The documented syscall ABI specifies that the SVE state not shared with
FPSIMD is undefined after a syscall. Currently we implement this by
always flushing this register state to zero, ensuring consistent
behaviour but introducing some overhead in the case where we can return
directly to userspace
In order to avoid needlessly saving and restoring the guest registers KVM
relies on the host FPSMID code to save the guest registers when we context
switch away from the guest. This is done by binding the KVM guest state to
the CPU on top of the task state that was originally there, then carefully
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.
The SME state detauls are already recorded
On Tue, 7 Jun 2022 14:14:24 +0100, Marc Zyngier wrote:
> This is a followup from [1], which aims at fixing userspace access to
> interrupt pending state for HW interrupts.
>
> * From v1 [1]:
> - Keep some of the GICv3-specifics around to avoid regressing the
> line vs latch distinction
Hi Marc,
On 6/7/22 15:14, Marc Zyngier wrote:
> Now that GICv2 has a proper userspace accessor for the pending state,
> switch GICv3 over to it, dropping the local version, moving over the
> specific behaviours that CGIv3 requires (such as the distinction
> between pending latch and line level
17 matches
Mail list logo
