[+KVM/ARM folks, since I can't take this without an Ack in place from them]
My understanding is that this patch is intended to replace patch 3/4 in
this series:
http://lists.infradead.org/pipermail/linux-arm-kernel/2019-March/638083.html
On Tue, Mar 12, 2019 at 06:55:45PM +0530, Anshuman Khandua
Hi Suzuki,
On 3/28/19 2:36 PM, Marc Zyngier wrote:
> From: Suzuki K Poulose
>
> commit 6794ad5443a2118 ("KVM: arm/arm64: Fix unintended stage 2 PMD mappings")
> made the checks to skip huge mappings, stricter. However it introduced
> a bug where we still use huge mappings, ignoring the flag to
>
From: Dave Martin
Some optional features of the Arm architecture add new system
registers that are not present in the base architecture.
Where these features are optional for the guest, the visibility of
these registers may need to depend on some runtime configuration,
such as a flag passed to K
Currently hyp_symbol_addr is placed in kvm_mmu.h which is mostly
used by __hyp_this_cpu_ptr in kvm_asm.h but it cannot include
kvm_mmu.h directly as kvm_mmu.h uses kvm_ksym_ref which is
defined inside kvm_asm.h. Hence, hyp_symbol_addr is moved inside
kvm_asm.h to fix this dependency on each other.
Save host MDCR_EL2 value during kvm HYP initialisation and restore
after every switch from host to guest. There should not be any
change in functionality due to this.
The value of mdcr_el2 is now stored in struct kvm_cpu_context as
both host and guest can now use this field in a common way.
Signe
From: Dave Martin
Architecture features that are conditionally visible to the guest
will require run-time checks in the ID register accessor functions.
In particular, read_id_reg() will need to perform checks in order
to generate the correct emulated value for certain ID register
fields such as I
Hi,
This patch series adds pointer authentication support for KVM guest and
is based on top of Linux 5.1-rc3. The basic patches in this series was
originally posted by Mark Rutland earlier[1,2] and contains some history
of this work.
Extension Overview:
===
From: Mark Rutland
When restoring HCR_EL2 for the host, KVM uses HCR_HOST_VHE_FLAGS, which
is a constant value. This works today, as the host HCR_EL2 value is
always the same, but this will get in the way of supporting extensions
that require HCR_EL2 bits to be set conditionally for the host.
To
Since Pointer authentication will be enabled or disabled on a
per-vcpu basis, vcpu feature flags are added in order to know which
vcpus have it enabled from userspace.
This features will allow the KVM guest to allow the handling of
pointer authentication instructions or to treat them as undefined
This patch advertises the capability of two cpu feature called address
pointer authentication and generic pointer authentication. These
capabilities depend upon system support for pointer authentication and
VHE mode.
The current arm64 KVM partially implements pointer authentication and
support of
From: Mark Rutland
When pointer authentication is supported, a guest may wish to use it.
This patch adds the necessary KVM infrastructure for this to work, with
a semi-lazy context switch of the pointer auth state.
Pointer authentication feature is only enabled when VHE is built
in the kernel an
This is a runtime capabality for KVM tool to enable Arm64 8.3 Pointer
Authentication in guest kernel. Two vcpu features
KVM_ARM_VCPU_PTRAUTH_[ADDRESS/GENERIC] are supplied together to enable
Pointer Authentication in KVM guest after checking the capability.
A command line option --ptrauth is also
On Fri, 29 Mar 2019 13:00:41 +,
Dave Martin wrote:
>
> In preparation for adding logic to filter out some KVM_REG_ARM_CORE
> registers from the KVM_GET_REG_LIST output, this patch factors out
> the core register enumeration into a separate function and rebuilds
> num_core_regs() on top of it.
Hi Dave,
On Tue, Mar 19, 2019 at 11:26 PM Dave Martin wrote:
>
> Some optional features of the Arm architecture add new system
> registers that are not present in the base architecture.
>
> Where these features are optional for the guest, the visibility of
> these registers may need to depend on
On Mon, Apr 01, 2019 at 05:16:38PM +0100, Will Deacon wrote:
> [+KVM/ARM folks, since I can't take this without an Ack in place from them]
>
> My understanding is that this patch is intended to replace patch 3/4 in
> this series:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-Marc
15 matches
Mail list logo