Clean up:
List modules in android/gki_system_dlkm_modules
in a sorted order. List of modules are not order
dependent in this file. Initially it was meant to
keep same as android/gki_aarch64_modules which has
order dependencies due to being used as MODULE_ORDER
if building using build.sh. kleaf doesn't use
android/gki_aarch64_modules and it should be deleted
as part of final switch to kleaf.
Bug: 232431411
Test: TH
Change-Id: I8a5ce0f3466d4322ed956a4cb3d2f9c8ef075a86
Signed-off-by: Ramji Jiyani <ramjiyani@google.com>
In aosp/1979327 we attempted to prevent tasks with pending signals and
PF_FREEZER_SKIP from being immediately rescheduled, because such tasks
would crash the kernel if run while no capable CPUs were online. This was
implemented by declining to immediately reschedule them unless various
conditions were met. However, this ended up causing signals to fail to
be delivered if the signal was received while a task is processing a
syscall, such as futex(2), that will block with PF_FREEZER_SKIP set,
as the kernel relies on a check for TIF_SIGPENDING after setting the
task state to TASK_INTERRUPTIBLE in order to deliver such a signal.
This patch is an alternative solution to the original problem that
avoids introducing the signal delivery bug. It works by changing
how freezer_should_skip() is implemented. Instead of just checking
PF_FREEZER_SKIP, we also use the on_rq field to check whether the task
is not on a runqueue. In this way we ensure that a task that will be
immediately rescheduled will not return true from freezer_should_skip(),
and the task will block the freezer unless it is actually taken off
the runqueue.
Signed-off-by: Peter Collingbourne <pcc@google.com>
Bug: 202918514
Bug: 251700836
Change-Id: I3f9b705ce9ad2ca1d2df959f43cf05bef78560f8
Create a generic global list for GKI modules' list
and use that instead of cluttering the long list in
every target to keep it more robust and readable.
Bug: 232431151
Test: TH
Change-Id: Ib7f7be7988204c483519be0b38a90007d54b7912
Signed-off-by: Ramji Jiyani <ramjiyani@google.com>
crypto_tfm::__crt_ctx is not guaranteed to be 16-byte aligned on x86-64.
This causes crashes due to movaps instructions in clmul_polyval_update.
Add logic to align polyval_tfm_ctx to 16 bytes.
Cc: <stable@vger.kernel.org>
Fixes: 34f7f6c301 ("crypto: x86/polyval - Add PCLMULQDQ accelerated implementation of POLYVAL")
Reported-by: Bruno Goncalves <bgoncalv@redhat.com>
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Bug: 233652475
(cherry picked from commit 9f6035af06)
Change-Id: I6f95f67b7118d5ad981a93641adb62af5cac3768
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
The ddk_headers targets should be architecture specific; that
is, an x86_64 ddk_module should not be able to see arm64 headers,
and vice versa.
Since the majority of devices is arm64, the //common:all_headers
alias points to //common:all_headers_aarch64. x86_64 devices
can use //common:all_headers_x86_64 instead.
After this change:
- arm64 ddk_modules can continue depending on //common:all_headers, or
they can depend on //common:all_headers_aarch64 to be explicit.
In this case, they will not see the x86 headers.
- x86 ddk_modules can depend on //common:all_headers_x86_64.
In this case, they will not see the arm64 headers.
- unsafe headers under drivers/ are not splitted; they aren't arch specific.
This change ensures that e.g. virtual_device_x86_64 does not
search the headers from the arm64 folders.
Test: bazel build //common:all_headers
Test: bazel build --allow_ddk_unsafe_headers_set //common:all_headers
Bug: 256225968
Signed-off-by: Yifan Hong <elsk@google.com>
Change-Id: I80dd33fb4c0e93dcba3e0714f9fd67d78596ab15
Add buildifier sorting directives for modules lists
to catch non sorted lists in presubmit as well as
to help sort lists using the buildifier.
Bug: 232431151
Test: TH
Change-Id: I508652429f26f85ce5d760024574d68d63f2da9e
Signed-off-by: Ramji Jiyani <ramjiyani@google.com>
In preparation of going away from the build.config.*,
remove the comments to keep bazel in sync with them.
Bug: 232431151
Test: TH
Change-Id: Iadf09d1a7c5afbbfdafb8225471352a48842be34
Signed-off-by: Ramji Jiyani <ramjiyani@google.com>
Sort modules listing in an ascending order,
since order is not important.
Bug: 232431151
Test: TH
Change-Id: Icaad772671bf3d6a78ce1fda84b3a6fe566df0f6
Signed-off-by: Ramji Jiyani <ramjiyani@google.com>
When using nVHE in protected mode, the host donates pages through an arch
specific memcache the hyp can then pours in its local vcpu copy. The latter
should be flushed on VM teardown.
Bug: 237506543
Change-Id: Ic37d794ac33e9f844fa6ae1b4943febcdad5b033
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Enable zram and zsmalloc as modules to be in sync
with the aarch64 builds.
Bug: 232431151
Test: TH
Signed-off-by: Ramji Jiyani <ramjiyani@google.com>
Change-Id: I55053eeb6beda342689c854f95f4307871a3729b
Remove zram & zsmalloc symbols from abi_gki_aarch64.
This makes these modules as protected until some partner
adds these symbols in their symbol list to override them.
This also cleans up the generic symbol list as per the
GKI modules symbol handling i.e. GKI modules don't contribute
to the KMIs until they are being override by the partners.
Bug: 232431151
Test: TH
Signed-off-by: Ramji Jiyani <ramjiyani@google.com>
Change-Id: I30fb0a46f306d1efdc7e174725066dcc86040e80
This CL includes headers used by the external modules
of virtual_device_x86_64.
Allowlist: This is a list of headers and a list of
include directories that are known to be safe
to be used by modules.
- This list includes:
- Everything under
- arch/x86/include
- include
Unsafe list: This is the list of headers that are known to be used
by the external modules of virtual_device_x86_64, minus allowlist.
This means, with the allowlist and unsafe list, the certain Pixel
device kernel build can be transitioned to DDK without any change
to the source code.
- Note that for cleaness of DDK modules, we may want to
remove some items in the allowlist of includes and
require device source code to #include from the
correct directory.
The command to generate this list is:
bazel run //build/kernel/kleaf:gen_ddk_headers \
--gen_ddk_headers_target=//common-modules/virtual-device:virtual_device_x86_64_modules_install \
--gen_ddk_headers_input_archives=//common:kernel_x86_64_ddk_allowlist_headers \
-- -k
Manual edits:
- arch/arm64/include/ is added back. This is due to a limitation
of the generation script that globs aren't properly handled.
Bug: 248351908
Signed-off-by: Yifan Hong <elsk@google.com>
Change-Id: I0eae9213493d78a6899aa15c8096f3c7694328a3
Some hardware has a way to restore all keyslots at once that is
significantly faster than restoring each keyslot individually, as is
done by blk_ksm_reprogram_all_keys(). Add a hook
"android_rvh_ufs_reprogram_all_keys" that allows overriding the
restoration of all keyslots after UFS reset. This may sleep, so this
must be a "restricted" Android vendor hook rather than a regular one.
Note that currently this functionality can't be upstreamed, as support
for the hardware that needs it would need to be upstreamed first.
(cherry picked from commit e2e063f507)
Bug: 162257402
Bug: 181905172
Bug: 241106918
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Kenny Root <kroot@google.com>
Change-Id: I0b25393a5131941f085892560e08a64e63cd1369
Expose a new capability, KVM_CAP_ARM_PROTECTED_VM, for protected VMs
which allows the size of the PVM firmware region to be discovered from
userspace and for the firmware load address to be specified if it is
required.
Signed-off-by: Will Deacon <will@kernel.org>
[willdeacon@: Fix trivial conflict in include/uapi/linux/kvm.h with
other KVM_CAP_* definitions from upstream]
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 254819795
Change-Id: I819b9b2cfa227f1a0607a8f683aa01d4ae50704f
When a PVM firmware image is present for a protected VM, treat the first
running vCPU as the "primary" vCPU and reset its registers accordingly,
in particular by initialising its PC to enter the firmware at startup.
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 254819795
Change-Id: I26676637145c7d809c5dc5ac0ad0e1fadaf275d2
When the host donates a page to a protected guest at an IPA which
coincides with the PVM firmware load address, copy-in the relevant
firmware page after unmapping it from the host but before mapping it
into the guest.
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 254819795
Change-Id: I8cec813fa52938945f3122655deb785523a96ec8
When the host shuts down cleanly under pKVM, it is EL2's responsibility
to clear the pvmfw pages before forwarding the PSCI call onto EL3.
Wipe the pvmfw pages on SYSTEM_OFF, SYSTEM_RESET and SYSTEM_RESET2 calls
from the host, cleaning the zeroed memory to the PoC for good measure.
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 254819795
Change-Id: I0dd2757e355f384813319034c6eed0fa2c2328c2
kvm_flush_dcache_to_poc() converts its (start,len) parameters into
(start,end) parameters for dcache_clean_inval_poc(). This mostly works
out except for the case when 'len == 0', where dcache_clean_inval_poc()
will still issue cache maintenance for the cache line containing 'start'.
If 'start' is not mapped, then this can generate an unexpected fault.
In preparation for cleaning the pvmfw memory pages to the PoC on
system reset, tweak kvm_flush_dcache_to_poc() to act as a no-op when
the supplied length is 0 and avoid having to check for this corner case
in the caller.
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 254819795
Change-Id: Idae2b22289398e941938821d1d3b3a5a1da3fd8f
Unmap the PVM firmware memory from the pKVM host by transferring
ownership of the pages to the hypervisor when the host deprivileges
itself during boot.
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 254819795
Change-Id: I311642f543c0c73d0e0cf2ec051e8e2d9759c5d1
Add support for a "linux,pkvm-guest-firmware-memory" reserved memory
region, which can be used to identify a firmware image for protected
VMs. If pKVM fails to initialise and a firmware region is advertised,
then the memory is cleared during boot.
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 254819795
Change-Id: Ibfcc0ff00d4b8a42747452047856cb9ba8def4c4
This CL includes headers used by the external modules of
a real Pixel device.
Allowlist: This is a list of headers and a list of
include directories that are known to be safe
to be used by modules.
- This list includes:
- Everything under
- arch/arm64/include
- include
Unsafe list: This is the list of headers that are known to be used
by a certain Pixel device kernel build, minus allowlist.
This means, with the allowlist and unsafe list, the certain Pixel
device kernel build can be transitioned to DDK without any change
to the source code.
- Note that for cleaness of DDK modules, we may want to
remove some items in the allowlist of includes and
require device source code to #include from the
correct directory.
The command to generate this list is:
bazel run //build/kernel/kleaf:gen_ddk_headers \
--gen_ddk_headers_target=//gs/google-modules/soc-modules:slider_modules_install
-- -k
Manual edits:
- manually removed the following headers that no longer exist on
android14-5.15:
remove hdrs arch/arm64/kvm/hyp/include/nvhe/ffa.h|//common:all_headers_unsafe
remove hdrs arch/arm64/kvm/hyp/include/nvhe/iommu.h|//common:all_headers_unsafe
remove hdrs arch/arm64/kvm/hyp/include/nvhe/pkvm.h|//common:all_headers_unsafe
remove hdrs drivers/scsi/ufs/ufs.h|//common:all_headers_unsafe
remove hdrs drivers/scsi/ufs/ufs_quirks.h|//common:all_headers_unsafe
remove hdrs drivers/scsi/ufs/ufshcd.h|//common:all_headers_unsafe
remove hdrs drivers/scsi/ufs/ufshcd-crypto.h|//common:all_headers_unsafe
remove hdrs drivers/scsi/ufs/ufshcd-pltfrm.h|//common:all_headers_unsafe
remove hdrs drivers/scsi/ufs/ufshci.h|//common:all_headers_unsafe
remove hdrs drivers/scsi/ufs/unipro.h|//common:all_headers_unsafe
- manually remove a source:
remove hdrs lib/vdso/gettimeofday.c|//common:all_headers_unsafe
Bug: 248351908
Change-Id: Ie75c45f1646ec6055dcdb6f49d3001691581c046
Signed-off-by: Yifan Hong <elsk@google.com>
Create the skeleton rules for DDK headers, and write comments
with hands.
This CL has no real effect; all targets are declared empty
and content is filled in in follow up CLs.
Allowlist: This is a list of headers and a list of
include directories that are known to be safe
to be used by modules.
Unsafe list: This is the list of headers that are known to be used
by some device kernel build, minus allowlist.
This means, with the allowlist and unsafe list, an unspecified
device kernel build can be transitioned to DDK without any change
to the source code.
- Note that for cleaness of DDK modules, we may want to
remove some items in the allowlist of includes and
require device source code to #include from the
correct directory.
Bug: 248351908
Signed-off-by: Yifan Hong <elsk@google.com>
Change-Id: I4f15d2fac703bc3b7100a72e90f289236db3e7e5
With some PCIe topologies, restoring a guest fails while
parsing the ITS device tables.
Reproducer hints:
1. Create ARM virt VM with pxb-pcie bus which adds
extra host bridges, with qemu command like:
```
-device pxb-pcie,bus_nr=8,id=pci.x,numa_node=0,bus=pcie.0 \
-device pcie-root-port,..,bus=pci.x \
...
-device pxb-pcie,bus_nr=37,id=pci.y,numa_node=1,bus=pcie.0 \
-device pcie-root-port,..,bus=pci.y \
...
```
2. Ensure the guest uses 2-level device table
3. Perform VM migration which calls save/restore device tables
In that setup, we get a big "offset" between 2 device_ids,
which makes unsigned "len" round up a big positive number,
causing the scan loop to continue with a bad GPA. For example:
1. L1 table has 2 entries;
2. and we are now scanning at L2 table entry index 2075 (pointed
to by L1 first entry)
3. if next device id is 9472, we will get a big offset: 7397;
4. with unsigned 'len', 'len -= offset * esz', len will underflow to a
positive number, mistakenly into next iteration with a bad GPA;
(It should break out of the current L2 table scanning, and jump
into the next L1 table entry)
5. that bad GPA fails the guest read.
Fix it by stopping the L2 table scan when the next device id is
outside of the current table, allowing the scan to continue from
the next L1 table entry.
Thanks to Eric Auger for the fix suggestion.
Fixes: 920a7a8fa9 ("KVM: arm64: vgic-its: Add infrastructure for tableookup")
Suggested-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Eric Ren <renzhengeek@gmail.com>
[maz: commit message tidy-up]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/d9c3a564af9e2c5bf63f48a7dcbf08cd593c5c0b.1665802985.git.renzhengeek@gmail.com
(cherry picked from commit c000a26071)
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Bug: 233588291
Change-Id: I451a60515a68e2f5386b190c0c09e6a476bd5e90
This reverts commit 17ff52af66.
With basic support for protected VMs, we can once again boot with KVM in
protected mode.
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: I15c41462b7fad4d3c5d5310674c0da385086d1c5
Add some initial documentation for the Protected KVM (pKVM) feature on
arm64, describing the user ABI for creating protected VMs as well as
their limitations.
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: I152af404f24b9aba3cc9be6acd8e26afcfa4b0a5
Introduce a new virtual machine type, KVM_VM_TYPE_ARM_PROTECTED, which
specifies that the guest memory pages are to be unmapped from the host
stage-2 by the hypervisor.
Signed-off-by: Will Deacon <will@kernel.org>
[willdeacon@: Align KVM_VM_TYPE_ARM_PROTECTED value with android13 kernels]
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: Iabcd03865aed4a41637597ac247897fd185bfc4d
Extend our KVM "vendor" hypercalls to expose three new hypercalls to
protected guests for the purpose of opening and closing shared memory
windows with the host:
MEMINFO: Query the stage-2 page size (i.e. the minimum granule at
which memory can be shared)
MEM_SHARE: Share a page RWX with the host, faulting the page in if
necessary.
MEM_UNSHARE: Unshare a page with the host. Subsequent host accesses
to the page will result in a fault being injected by the
hypervisor.
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: I80fe8af0bc0b3a40460c5065eabe26b1d9f634f2
The PTP hypercall documentation doesn't produce the best-looking table
when formatting in HTML as all of the return value definitions end up
on the same line.
Reformat the PTP hypercall documentation to follow the formatting used
by hypercalls.rst.
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: Ic77cea5a621a9278d098afd80ef4c0e125760814
KVM/arm64 makes use of the SMCCC "Vendor Specific Hypervisor Service
Call Range" to expose KVM-specific hypercalls to guests in a
discoverable and extensible fashion.
Document the existence of this interface and the discovery hypercall.
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: I5754589b1b695828eab7cb41c7aa6a0fb55ad273
In preparation for describing the guest view of KVM/arm64 hypercalls in
hypercalls.rst, move the existing contents of the file concerning the
firmware pseudo-registers elsewhere.
Cc: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: Ie8931290b291c0ffd2f1f11265babe2475972868
A guest that can only operate on private memory is pretty useless, as it
has no way to share buffers with the host for things like virtio.
Extend our memory protection mechanisms to support the sharing and
unsharing of guest pages from the guest to the host. For now, this
functionality is unused but will later be exposed to the guest via
hypercalls.
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: I6b0d6f63348f3a2a847acf4d7bb87bd6e9742af0
Break-before-make (BBM) can be expensive, as transitioning via an
invalid mapping (i.e. the "break" step) requires the completion of TLB
invalidation and can also cause other agents to fault concurrently on
the invalid mapping.
Since BBM is not required when changing only the software bits of a PTE,
avoid the sequence in this case and just update the PTE directly.
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: I91ec043a75154fa2ca732f5269c6ae1bceea4a93
Typically, TLB invalidation of guest stage-2 mappings using nVHE is
performed by a hypercall originating from the host. For the invalidation
instruction to be effective, therefore, __tlb_switch_to_{guest,host}()
swizzle the active stage-2 context around the TLBI instruction.
With guest-to-host memory sharing and unsharing hypercalls originating
from the guest under pKVM, there is now a need to support both guest
and host VMID invalidations issued from guest context.
Replace the __tlb_switch_to_{guest,host}() functions with a more general
{enter,exit}_vmid_context() implementation which supports being invoked
from guest context and acts as a no-op if the target context matches the
running context.
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: I92c6f48eb4c4b6286b930c2f0cda245bccc1927b
The pKVM hypervisor will currently panic if the host tries to access
memory that it doesn't own (e.g. protected guest memory). Sadly, as
guest memory can still be mapped into the VMM's address space, userspace
can trivially crash the kernel/hypervisor by poking into guest memory.
To prevent this, inject the abort back in the host with S1PTW set in the
ESR, hence allowing the host to differentiate this abort from normal
userspace faults and inject a SIGSEGV cleanly.
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: I09ee54fbf4c202dc3ac2e1b5eea264d4dc84f613
In order to simplify the injection of exceptions in the host in pkvm
context, let's factor out of enter_exception64() the code calculating
the exception offset from VBAR_EL1 and the cpsr.
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: I50a2510b59311717c6e17ea4e45fc634b4b43073
Add a helper allowing to check when the pkvm static key is enabled to
ease the introduction of pkvm hooks in other parts of the code.
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: I8995021768def73bd7636a84059bdc43fa7ab2fc
Now that TLBI invalidation is handled entirely at EL2 for both protected
and non-protected guests when protected KVM has initialised, unplug the
unused TLBI hypercalls.
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: I50ad4cb930c43f88e00320e47b358613224dd1cc
Factor out logic that resets a vcpu's core registers, including
additional PSCI handling. This code will be reused when resetting
VMs in protected mode.
Signed-off-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: I22468be1d382e05e39557e32ea09a023173dbf48
Move some PSCI functions and macros to a shared header to be used
by hyp in protected mode.
No functional change intended.
Signed-off-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: Ibe84564f423cd0281f3dc33d9801b474fe8f2db9
Move the macro defines of the pstate reset values to a shared
header to be used by hyp in protected mode.
No functional change intended.
Signed-off-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: Ib98734d2ced07a958427c6552a9c22d159b85ad1
Rather than forwarding guest hypercalls back to the host for handling,
implement some basic handling at EL2 which will later be extending to
provide additional functionality such as PSCI.
Signed-off-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: I14613c416078818b25bb29ed8899d7b71f8c40cc
When dealing with a guest with SVE enabled, make sure the host SVE
state is pinned at EL2 S1, and that the hypervisor vCPU state is
correctly initialised (and then unpinned on teardown).
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: Ic4d0ef9a6124701026cd56f6725ab4737857ed5b
Do not rely on the state of the vm as provided by the host, but
initialize it instead at EL2 to a known good and safe state.
Signed-off-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: I8e0e9fd7cdf0b5b4d422260be06920d0550d5f91
Move kvm_vcpu_enable_ptrauth() to a shared header to be used by
hyp in protected mode.
No functional change intended.
Signed-off-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: Idb90ae3228fc3acb1fe310227a4f606f47b026a5
Protected vCPUs always run with a virtual counter offset of 0, so don't
bother trying to update it from the host.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 233587962
Change-Id: I02a30687e36886aa5c97439874e3e4cf066fe6e7
