Sorry for spamming to/cc, Since my mail client footer not set so re-sending to
list.
Hi Marc,
Thanks for the review comment.
On 10/23/2020 4:59 PM, Marc Zyngier wrote:
Hi Santosh,
Thanks for this.
On 2020-10-21 17:16, Santosh Shukla wrote:
The Commit:6d674e28 introduces a notion to detec
Hi Marc,
Thanks for the review comment.
On 10/23/2020 4:59 PM, Marc Zyngier wrote:
Hi Santosh,
Thanks for this.
On 2020-10-21 17:16, Santosh Shukla wrote:
The Commit:6d674e28 introduces a notion to detect and handle the
device mapping. The commit checks for the VM_PFNMAP flag is set
in vma-
On Mon, Oct 26, 2020 at 09:23:31AM +1100, Gavin Shan wrote:
> On 10/25/20 8:52 PM, Marc Zyngier wrote:
> > On Sun, 25 Oct 2020 01:27:37 +0100,
> > Gavin Shan wrote:
> > >
> > > The 52-bits physical address is disabled until CONFIG_ARM64_PA_BITS_52
> > > is chosen. This uses option for that check,
On 2020-10-25 22:23, Gavin Shan wrote:
Hi Marc,
On 10/25/20 8:52 PM, Marc Zyngier wrote:
On Sun, 25 Oct 2020 01:27:37 +0100,
Gavin Shan wrote:
The 52-bits physical address is disabled until
CONFIG_ARM64_PA_BITS_52
is chosen. This uses option for that check, to avoid the
unconditional
chec
On 2020-10-25 23:04, Gavin Shan wrote:
Hi Marc,
On 10/25/20 9:48 PM, Marc Zyngier wrote:
On Sun, 25 Oct 2020 01:27:39 +0100,
Gavin Shan wrote:
The huge page could be mapped through multiple contiguous PMDs or
PTEs.
The corresponding huge page sizes aren't supported by the page table
walker
Setting PSTATE.PAN when entering EL2 on nVHE doesn't make much
sense as this bit only means something for translation regimes
that include EL0. This obviously isn't the case in the nVHE case,
so let's drop this setting.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/hyp/nvhe/host.S | 2 --
1 fil
Directly using the kimage_voffset variable is fine for now, but
will become more problematic as we start distrusting EL1.
Instead, patch the kimage_voffset into the HYP text, ensuring
we don't have to load an untrusted value later on.
Signed-off-by: Marc Zyngier
---
arch/arm64/kernel/image-vars
KVM/arm64 is so far unable to deal with function pointers, as the compiler
will generate the kernel's runtime VA, and not the linear mapping address,
meaning that kern_hyp_va() will give the wrong result.
We so far have been able to use PC-relative addressing, but that's not
always easy to use, an
This small series reworks various bits of the host EL2 entry after
Andrew's extensive rework to move from direct function calls to a
SMCCC implementation.
The first 3 patches are plain bug fixes, and candidates for immediate
merge into 5.10.
The following 2 patches allow the use of direct functio
Now that we can use function pointer, use a dispatch table to call
the individual HVC handlers, leading to more maintainable code.
Further improvements include helpers to declare the mapping of
local variables to values passed in the host context.
Signed-off-by: Marc Zyngier
---
arch/arm64/kern
Registers x0/x1 get repeateadly pushed and poped during a host
HVC call. Instead, leave the registers on the stack, saving
a store instruction on the fast path for an add on the slow path.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/hyp/nvhe/host.S | 5 ++---
1 file changed, 2 insertions(+),
The new calling convention says that pointers coming from the SMCCC
interface are turned into their HYP version in the host HVC handler.
However, there is still a stray kern_hyp_va() in the TLB invalidation
code, which could result in a corrupted pointer.
Drop the spurious conversion.
Fixes: a071
Move the setting of SSBS directly into the HVC handler, using
the C helpers rather than the inline asssembly code.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_asm.h| 2 --
arch/arm64/include/asm/sysreg.h | 1 +
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 6 +-
arch/arm64/
The hyp-init code starts by stashing a register in TPIDR_EL2
in in order to free a register. This happens no matter if the
HVC call is legal or not.
Although nothing wrong seems to come out of it, it feels odd
to alter the EL2 state for something that eventually returns
an error.
Instead, use the
On 10/26/20 9:51 AM, Marc Zyngier wrote:
> Setting PSTATE.PAN when entering EL2 on nVHE doesn't make much
> sense as this bit only means something for translation regimes
> that include EL0. This obviously isn't the case in the nVHE case,
> so let's drop this setting.
>
> Signed-off-by: Marc Zyngi
The Commit:6d674e28 introduces a notion to detect and handle the
device mapping. The commit checks for the VM_PFNMAP flag is set
in vma->flags and if set then marks force_pte to true such that
if force_pte is true then ignore the THP function check
(/transparent_hugepage_adjust()).
There could be
Description of the Reproducer scenario as asked in the thread [1].
Tried to create the reproducer scenario with vfio-pci driver using
nvidia GPU in PT mode, As because vfio-pci driver now supports
vma faulting (/vfio_pci_mmap_fault) so could create a crude reproducer
situation with that.
To creat
On Wed, Oct 21, 2020 at 11:05:10AM +0100, Marc Zyngier wrote:
> On 2020-10-20 15:40, Rob Herring wrote:
> > On Thu, Sep 24, 2020 at 8:48 AM Rob Herring wrote:
> > >
> > > On Cortex-A77 r0p0 and r1p0, a sequence of a non-cacheable or device
> > > load
> > > and a store exclusive or PAR_EL1 read ca
In an effort to remove the vcpu PC manipulations from EL1 on nVHE
systems, move kvm_skip_instr() to be HYP-specific. EL1's intent
to increment PC post emulation is now signalled via a flag in the
vcpu structure.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_emulate.h | 27 +---
There is no need to feed the result of kvm_vcpu_trap_il_is32bit()
to kvm_skip_instr(), as only AArch32 has a variable lenght ISA, and
this helper can equally be called from kvm_skip_instr32(), reducing
the complexity at all the call sites.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/k
Add the basic infrastructure to describe injection of exceptions
into a guest. So far, nothing uses this code path.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_host.h | 31 --
arch/arm64/kvm/hyp/exception.c | 17
arch/arm64/kvm
The SPR setting code is now completely unused, including that dealing
with banked AArch32 SPSRs. Cleanup time.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_emulate.h | 26
arch/arm64/kvm/regmap.c | 96
2 files changed, 122 deletion
Move the AArch64 exception injection code from EL1 to HYP, leaving
only the ESR_EL1 updates to EL1. In order to come with the differences
between VHE and nVHE, two set of system register accessors are provided.
SPSR, ELR, PC and PSTATE are now completely handled in the hypervisor.
Signed-off-by:
Instead of handling the "PC rollback on SError during HVC" at EL1 (which
requires disclosing PC to a potentially untrusted kernel), let's move
this fixup to ... fixup_guest_exit(), which is where we do all fixups.
Isn't that neat?
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/handle_exit.c
As we are about to need to access system registers from the HYP
code based on their internal encoding, move the direct sysreg
accessors to a common include file.
No functionnal change.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_host.h | 85 +++
arch/a
Similarily to what has been done for AArch64, move the AArch32 exception
inhjection to HYP.
In order to not use the regmap selection code at EL2, simplify the code
populating the target mode's LR register by harcoding the two possible
LR registers (LR_abt in X20, LR_und in X22).
We also introduce
On SMC trap, the prefered return address is set to that of the SMC
instruction itself. It is thus wrong to tyr and roll it back when
an SError occurs while trapping on SMC. It is still necessary on
HVC though, as HVC doesn't cause a trap, and sets ELR to returning
*after* the HVC.
It also became a
As we progress towards being able to keep the guest state private to
the nVHE hypervisor, this series aims at moving anything that touches
the registers involved into an exception to EL2.
The general idea is that any update to these registers is driven by a
set of flags passed from EL1 to EL2, and
Currently has_vhe() detects whether it is being compiled for VHE/NVHE
hyp code based on preprocessor definitions, and uses this knowledge to
avoid redundant runtime checks.
There are other cases where we'd like to use this knowledge, so let's
factor the preprocessor checks out into separate helper
In a few places we use cpus_have_const_cap() in hyp code, usually
because this is hidden within a helper that's also used in regular
kernel context. As cpus_have_const_cap() generates code to read the
cpu_hwcaps array before capabilities are finalized, this means we
generate some potentially-unsoun
In a subsequent patch we'll modify cpus_have_const_cap() to call
cpus_have_final_cap(), and hence we need to define cpus_have_final_cap()
first.
To make subsequent changes easier to follow, this patch reorders the two
without making any other changes.
There should be no functional change as a res
We finalize caps before initializing kvm hyp code, and any use of
cpus_have_const_cap() in kvm hyp code generates redundant and
potentially unsound code to read the cpu_hwcaps array.
A number of helper functions used in both hyp context and regular kernel
context use cpus_have_const_cap(), as some
On Mon, Oct 26, 2020 at 01:34:40PM +, Marc Zyngier wrote:
> On SMC trap, the prefered return address is set to that of the SMC
> instruction itself. It is thus wrong to tyr and roll it back when
Typo: s/tyr/try/
> an SError occurs while trapping on SMC. It is still necessary on
> HVC though,
Move the AArch32 exception injection code back into the inject_fault.c
file, removing the need for a few non-static functions now that AArch32
host support is a thing of the past.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_emulate.h | 3 -
arch/arm64/kvm/Makefile |
The only use of the register mapping code was for the sake of the LR
mapping, which we trivially solved in a previous patch. Get rid of
the whole thing now.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_emulate.h | 2 -
arch/arm64/kvm/Makefile | 2 +-
arch/arm64/kvm
On Mon, Oct 26, 2020 at 01:34:41PM +, Marc Zyngier wrote:
> There is no need to feed the result of kvm_vcpu_trap_il_is32bit()
> to kvm_skip_instr(), as only AArch32 has a variable lenght ISA, and
Typo: s/lenght/length/
If there are more typos in the series, I'll ignore them. I assume you
know
On Mon, Oct 26, 2020 at 01:34:42PM +, Marc Zyngier wrote:
> In an effort to remove the vcpu PC manipulations from EL1 on nVHE
> systems, move kvm_skip_instr() to be HYP-specific. EL1's intent
> to increment PC post emulation is now signalled via a flag in the
> vcpu structure.
>
> Signed-off-b
On Mon, Oct 26, 2020 at 01:34:43PM +, Marc Zyngier wrote:
> Instead of handling the "PC rollback on SError during HVC" at EL1 (which
> requires disclosing PC to a potentially untrusted kernel), let's move
> this fixup to ... fixup_guest_exit(), which is where we do all fixups.
>
> Isn't that n
On Mon, Oct 26, 2020 at 01:34:44PM +, Marc Zyngier wrote:
> As we are about to need to access system registers from the HYP
> code based on their internal encoding, move the direct sysreg
> accessors to a common include file.
>
> No functionnal change.
>
> Signed-off-by: Marc Zyngier
Acked-
On 2020-10-26 13:53, Mark Rutland wrote:
On Mon, Oct 26, 2020 at 01:34:40PM +, Marc Zyngier wrote:
On SMC trap, the prefered return address is set to that of the SMC
instruction itself. It is thus wrong to tyr and roll it back when
Typo: s/tyr/try/
an SError occurs while trapping on SMC.
On Mon, Oct 26, 2020 at 01:34:46PM +, Marc Zyngier wrote:
> Move the AArch64 exception injection code from EL1 to HYP, leaving
> only the ESR_EL1 updates to EL1. In order to come with the differences
> between VHE and nVHE, two set of system register accessors are provided.
>
> SPSR, ELR, PC a
On Mon, Oct 26, 2020 at 02:08:35PM +, Marc Zyngier wrote:
> On 2020-10-26 13:53, Mark Rutland wrote:
> > Assuming that there is no 16-bit HVC:
>
> It is actually impossible to have a 16bit encoding for HVC, as
> it always convey a 16bit immediate, and you need some space
> to encode the instru
On Mon, Oct 26, 2020 at 01:34:47PM +, Marc Zyngier wrote:
> Similarily to what has been done for AArch64, move the AArch32 exception
> inhjection to HYP.
>
> In order to not use the regmap selection code at EL2, simplify the code
> populating the target mode's LR register by harcoding the two
On Mon, Oct 26, 2020 at 01:34:48PM +, Marc Zyngier wrote:
> The SPR setting code is now completely unused, including that dealing
> with banked AArch32 SPSRs. Cleanup time.
>
> Signed-off-by: Marc Zyngier
Acked-by: Mark Rutland
Mark.
> ---
> arch/arm64/include/asm/kvm_emulate.h | 26
For consistency with the rest of the stage-2 page-table page allocations
(performing using a kvm_mmu_memory_cache), ensure that __GFP_ACCOUNT is
included in the GFP flags for the PGD pages.
Cc: Marc Zyngier
Cc: Quentin Perret
Signed-off-by: Will Deacon
---
arch/arm64/kvm/hyp/pgtable.c | 2 +-
This series adds support for Arm's Memory Tagging Extension (MTE) to
KVM, allowing KVM guests to make use of it. This builds on the existing
user space support already in v5.10-rc1, see [1] for an overview.
[1] https://lwn.net/Articles/834289/
Changes since v3[2]:
* Rebased on v5.10-rc1 (requir
Add a new VM feature 'KVM_ARM_CAP_MTE' which enables memory tagging
for a VM. This exposes the feature to the guest and automatically tags
memory pages touched by the VM as PG_mte_tagged (and clears the tags
storage) to ensure that the guest cannot see stale tags, and so that the
tags are correctly
Define the new system registers that MTE introduces and context switch
them. The MTE feature is still hidden from the ID register as it isn't
supported in a VM yet.
Signed-off-by: Steven Price
Reviewed-by: Andrew Jones
---
arch/arm64/include/asm/kvm_host.h | 4
arch/arm64/include
kvm_get_hyp_vector() has only one caller, so move it out of kvm_mmu.h
and inline it into a new function, cpu_set_hyp_vector(), for setting
the vector.
Cc: Marc Zyngier
Cc: Quentin Perret
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/kvm_mmu.h | 43 -
arch/ar
Branch predictor hardening of the hyp vectors is partially driven by a
couple of global variables ('__kvm_bp_vect_base' and
'__kvm_harden_el2_vector_slot'). However, these are only used within a
single compilation unit, so internalise them there instead.
Cc: Marc Zyngier
Cc: Quentin Perret
Signe
The BP hardening helpers are an integral part of the Spectre-v2
mitigation, so move them into asm/spectre.h and inline the
arm64_get_bp_hardening_data() function at the same time.
Cc: Marc Zyngier
Cc: Quentin Perret
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/mmu.h | 29 -
The hardened hyp vectors are not used on systems running with VHE or CPUs
without the ARM64_HARDEN_EL2_VECTORS capability.
Re-jig the checking logic slightly in kvm_patch_vector_branch() so that
it's a bit clearer what we're looking for. This is purely cosmetic.
Cc: Marc Zyngier
Cc: Quentin Perr
Hi all,
This small series reworks the hyp vector handling for the vectors
installed when running a guest so that they are more amenable to the
ongoing "Protected KVM" efforts. Most of the patches here are cosmetic,
with the bulk of the changes living in patch seven.
The idea is to allocate the ve
'__kvm_bp_vect_base' is only used when dealing with the hardened vectors
so remove the redundant assignments in kvm_map_vectors().
Cc: Marc Zyngier
Cc: Quentin Perret
Signed-off-by: Will Deacon
---
arch/arm64/kvm/arm.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/arm64/kvm/arm.
Since ARM64_HARDEN_EL2_VECTORS is really a mitigation for Spectre-v3a,
rename it accordingly for consistency with the v2 and v4 mitigation.
Cc: Marc Zyngier
Cc: Quentin Perret
Signed-off-by: Will Deacon
---
Documentation/arm64/memory.rst | 2 +-
arch/arm64/include/asm/cpucaps.h | 2 +-
arc
The EL2 vectors installed when a guest is running point at one of the
following configurations for a given CPU:
- Straight at __kvm_hyp_vector
- A trampoline containing an SMC sequence to mitigate Spectre-v2 and
then a direct branch to __kvm_hyp_vector
- A dynamically-allocated trampolin
The spectre-v3a mitigation is split between cpu_errata.c and spectre.c,
with the former handling detection of the problem and the latter handling
enabling of the workaround.
Move the detection logic alongside the enabling logic, like we do for the
other spectre mitigations.
Cc: Marc Zyngier
Cc:
The bulk of the work in kvm_map_vector() is conditional on the
ARM64_HARDEN_EL2_VECTORS capability, so return early if that is not set
and make the code a bit easier to read.
Cc: Marc Zyngier
Cc: Quentin Perret
Signed-off-by: Will Deacon
---
arch/arm64/kvm/arm.c | 28 ++
On Monday 26 Oct 2020 at 09:51:09 (+), Marc Zyngier wrote:
> The hyp-init code starts by stashing a register in TPIDR_EL2
> in in order to free a register. This happens no matter if the
> HVC call is legal or not.
>
> Although nothing wrong seems to come out of it, it feels odd
> to alter the
On 10/26/20 7:53 PM, Marc Zyngier wrote:
On 2020-10-25 22:23, Gavin Shan wrote:
Hi Marc,
On 10/25/20 8:52 PM, Marc Zyngier wrote:
On Sun, 25 Oct 2020 01:27:37 +0100,
Gavin Shan wrote:
The 52-bits physical address is disabled until CONFIG_ARM64_PA_BITS_52
is chosen. This uses option for that
Hi Will,
On 10/27/20 1:44 AM, Will Deacon wrote:
For consistency with the rest of the stage-2 page-table page allocations
(performing using a kvm_mmu_memory_cache), ensure that __GFP_ACCOUNT is
included in the GFP flags for the PGD pages.
Cc: Marc Zyngier
Cc: Quentin Perret
Signed-off-by: Wil
Hi Santosh,
On 10/26/20 10:24 PM, Santosh Shukla wrote:
The Commit:6d674e28 introduces a notion to detect and handle the
device mapping. The commit checks for the VM_PFNMAP flag is set
in vma->flags and if set then marks force_pte to true such that
if force_pte is true then ignore the THP functi
62 matches
Mail list logo
