2019-07-31 17:15:23 +02:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
|
/*
|
|
|
|
|
* ucall support. A ucall is a "hypercall to userspace".
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2018, Red Hat, Inc.
|
|
|
|
|
*/
|
|
|
|
|
#include "kvm_util.h"
|
|
|
|
|
|
2023-07-31 13:30:24 -07:00
|
|
|
vm_vaddr_t *ucall_exit_mmio_addr;
|
2019-07-31 17:15:23 +02:00
|
|
|
|
2022-10-06 00:34:05 +00:00
|
|
|
void ucall_arch_init(struct kvm_vm *vm, vm_paddr_t mmio_gpa)
|
2019-07-31 17:15:23 +02:00
|
|
|
{
|
2022-12-09 01:53:04 +00:00
|
|
|
vm_vaddr_t mmio_gva = vm_vaddr_unused_gap(vm, vm->page_size, KVM_UTIL_MIN_VADDR);
|
|
|
|
|
|
|
|
|
|
virt_map(vm, mmio_gva, mmio_gpa, 1);
|
2019-07-31 17:15:23 +02:00
|
|
|
|
2022-10-06 00:34:08 +00:00
|
|
|
vm->ucall_mmio_addr = mmio_gpa;
|
2019-07-31 17:15:23 +02:00
|
|
|
|
2022-12-09 01:53:04 +00:00
|
|
|
write_guest_global(vm, ucall_exit_mmio_addr, (vm_vaddr_t *)mmio_gva);
|
2019-07-31 17:15:23 +02:00
|
|
|
}
|
|
|
|
|
|
2022-10-06 00:34:04 +00:00
|
|
|
void *ucall_arch_get_ucall(struct kvm_vcpu *vcpu)
|
2019-07-31 17:15:23 +02:00
|
|
|
{
|
2022-06-02 13:41:33 -07:00
|
|
|
struct kvm_run *run = vcpu->run;
|
2020-10-12 12:47:14 -07:00
|
|
|
|
2019-07-31 17:15:23 +02:00
|
|
|
if (run->exit_reason == KVM_EXIT_MMIO &&
|
2022-10-06 00:34:07 +00:00
|
|
|
run->mmio.phys_addr == vcpu->vm->ucall_mmio_addr) {
|
KVM: selftests: Add ucall pool based implementation
To play nice with guests whose stack memory is encrypted, e.g. AMD SEV,
introduce a new "ucall pool" implementation that passes the ucall struct
via dedicated memory (which can be mapped shared, a.k.a. as plain text).
Because not all architectures have access to the vCPU index in the guest,
use a bitmap with atomic accesses to track which entries in the pool are
free/used. A list+lock could also work in theory, but synchronizing the
individual pointers to the guest would be a mess.
Note, there's no need to rewalk the bitmap to ensure success. If all
vCPUs are simply allocating, success is guaranteed because there are
enough entries for all vCPUs. If one or more vCPUs are freeing and then
reallocating, success is guaranteed because vCPUs _always_ walk the
bitmap from 0=>N; if vCPU frees an entry and then wins a race to
re-allocate, then either it will consume the entry it just freed (bit is
the first free bit), or the losing vCPU is guaranteed to see the freed
bit (winner consumes an earlier bit, which the loser hasn't yet visited).
Reviewed-by: Andrew Jones <andrew.jones@linux.dev>
Signed-off-by: Peter Gonda <pgonda@google.com>
Co-developed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/r/20221006003409.649993-8-seanjc@google.com
2022-10-06 00:34:09 +00:00
|
|
|
TEST_ASSERT(run->mmio.is_write && run->mmio.len == sizeof(uint64_t),
|
2019-07-31 17:15:23 +02:00
|
|
|
"Unexpected ucall exit mmio address access");
|
KVM: selftests: Add ucall pool based implementation
To play nice with guests whose stack memory is encrypted, e.g. AMD SEV,
introduce a new "ucall pool" implementation that passes the ucall struct
via dedicated memory (which can be mapped shared, a.k.a. as plain text).
Because not all architectures have access to the vCPU index in the guest,
use a bitmap with atomic accesses to track which entries in the pool are
free/used. A list+lock could also work in theory, but synchronizing the
individual pointers to the guest would be a mess.
Note, there's no need to rewalk the bitmap to ensure success. If all
vCPUs are simply allocating, success is guaranteed because there are
enough entries for all vCPUs. If one or more vCPUs are freeing and then
reallocating, success is guaranteed because vCPUs _always_ walk the
bitmap from 0=>N; if vCPU frees an entry and then wins a race to
re-allocate, then either it will consume the entry it just freed (bit is
the first free bit), or the losing vCPU is guaranteed to see the freed
bit (winner consumes an earlier bit, which the loser hasn't yet visited).
Reviewed-by: Andrew Jones <andrew.jones@linux.dev>
Signed-off-by: Peter Gonda <pgonda@google.com>
Co-developed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/r/20221006003409.649993-8-seanjc@google.com
2022-10-06 00:34:09 +00:00
|
|
|
return (void *)(*((uint64_t *)run->mmio.data));
|
2019-07-31 17:15:23 +02:00
|
|
|
}
|
|
|
|
|
|
2022-10-06 00:34:04 +00:00
|
|
|
return NULL;
|
2019-07-31 17:15:23 +02:00
|
|
|
}
|