This patch adds 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.
Command line options
A per vcpu flag is added to check if pointer authentication is
enabled for the vcpu or not. This flag may be enabled according to
the necessary user policies and host capabilities.
This patch also adds a helper to check the flag.
Reviewed-by: Dave Martin
Signed-off-by: Amit Daniel Kachhap
Cc:
Now that the building blocks of pointer authentication are present, lets
add userspace flags KVM_ARM_VCPU_PTRAUTH_ADDRESS and
KVM_ARM_VCPU_PTRAUTH_GENERIC. These flags will enable pointer
authentication for the KVM guest on a per-vcpu basis through the ioctl
KVM_ARM_VCPU_INIT.
This features will
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
Hi,
This patch series adds pointer authentication support for KVM guest and
is based on top of Linux kvmarm/next repo. 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: Marc Zyngier
[ Upstream commit 7494cec6cb3ba7385a6a223b81906384f15aae34 ]
Calling kvm_is_visible_gfn() implies that we're parsing the memslots,
and doing this without the srcu lock is frown upon:
[12704.164532] =
[12704.164544] WARNING: suspicious RCU usage
From: Marc Zyngier
[ Upstream commit ebff0b0e3d3c862c16c487959db5e0d879632559 ]
We've become very cautious to now always reset the vcpu when nothing
is loaded on the physical CPU. To do so, we now disable preemption
and do a kvm_arch_vcpu_put() to make sure we have all the state
in memory (and
From: Marc Zyngier
[ Upstream commit 7494cec6cb3ba7385a6a223b81906384f15aae34 ]
Calling kvm_is_visible_gfn() implies that we're parsing the memslots,
and doing this without the srcu lock is frown upon:
[12704.164532] =
[12704.164544] WARNING: suspicious RCU usage
From: Marc Zyngier
[ Upstream commit a6ecfb11bf37743c1ac49b266595582b107b61d4 ]
When halting a guest, QEMU flushes the virtual ITS caches, which
amounts to writing to the various tables that the guest has allocated.
When doing this, we fail to take the srcu lock, and the kernel
shouts loudly
From: Suzuki K Poulose
[ Upstream commit 3c3736cd32bf5197aed1410ae826d2d254a5b277 ]
We rely on the mmu_notifier call backs to handle the split/merge
of huge pages and thus we are guaranteed that, while creating a
block mapping, either the entire block is unmapped at stage2 or it
is missing
From: Marc Zyngier
[ Upstream commit ca71228b42a96908eca7658861eafacd227856c9 ]
The normal interrupt flow is not to enable the vgic when no virtual
interrupt is to be injected (i.e. the LRs are empty). But when a guest
is likely to use GICv4 for LPIs, we absolutely need to switch it on
at all
From: Marc Zyngier
[ Upstream commit ebff0b0e3d3c862c16c487959db5e0d879632559 ]
We've become very cautious to now always reset the vcpu when nothing
is loaded on the physical CPU. To do so, we now disable preemption
and do a kvm_arch_vcpu_put() to make sure we have all the state
in memory (and
From: Marc Zyngier
[ Upstream commit a6ecfb11bf37743c1ac49b266595582b107b61d4 ]
When halting a guest, QEMU flushes the virtual ITS caches, which
amounts to writing to the various tables that the guest has allocated.
When doing this, we fail to take the srcu lock, and the kernel
shouts loudly
From: Suzuki K Poulose
[ Upstream commit a80868f398554842b14d07060012c06efb57c456 ]
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: Marc Zyngier
[ Upstream commit 7494cec6cb3ba7385a6a223b81906384f15aae34 ]
Calling kvm_is_visible_gfn() implies that we're parsing the memslots,
and doing this without the srcu lock is frown upon:
[12704.164532] =
[12704.164544] WARNING: suspicious RCU usage
16 matches
Mail list logo
