Hello,
Continuing the discussion from [1], the series tries to add support
for the user-space to elect the hypercall services that it wishes
to expose to the guest, rather than the guest discovering them
unconditionally. The idea employed by the series was taken from
[1] as suggested by Marc Z.
In a broad sense, the idea is similar to the current implementation
of PSCI interface- create a 'psuedo-firmware register' to handle the
firmware revisions. The series extends this idea to all the other
hypercalls such as TRNG (True Random Number Generator), PV_TIME
(Paravirtualized Time), and PTP (Precision Time protocol).
For better categorization and future scaling, firmware registers
are introduced based on the SMCCC service call owner (standard secure
service, standard hypervisor service, and vendor specific hypervisor
service). Each of these registers exposes the features employed in
the form of a bitmap and are enveloped into a generic interface (for
future expansion).
Upon VM creation, all the features supported by each owner type are
enabled. User-space/VMM can learn about the services currently enabled
via GET_ONE_REG and can manipulate them via SET_ONE_REG interfaces.
These 'writes' directly effect the bitmap, which is further checked
when the guest tries to issue the hypercall and a decision is taken
weather or not the hypercall is accessable to the guest. The interface
works well across live-migrations where the VMM can simply save/restore
these firmware registers using the existing IOCTL interfaces.
Upon VM start (at least one vCPU runs), the registers become read-only
and cannot be manupulated by the VMM. This is just to avoid providing
conflicting views of the services to the guests.
One of the problems that the series need to address is the enablement
of the features carried by a firmware register, whose existance is
not known to the VMM yet. A couple of ideas were discussed to handle this:
1) Upon the first SET_ONE_REG, clear all the firmware registers
implicitly. It's the responsibility of the VMM to make sure that it
configures all the registers that's known to it.
2) Contrary to #1, which implicitly clears all the registers, introduce
a new capability to handle this explicitly. That is, the after learning
about the services supported by the host, the VMM writes to the
capability to explictly clear the registers.
The series currently employs #1 just for the sake of completion, but is
open for further discussion.
The patches are based off of kvmarm-next 5.15-rc4, with the selftest
patches from [2] applied.
Patch-1 factors out the non-PSCI related interface from psci.c to
hypercalls.c, as the series would extend the list in the upcoming
patches.
Patch-2 sets up a base environment to handle the 'writes' of firmware
register- clear all the registers upon first 'write' and block 'writes'
to the registers upon VM start.
Patch-3 introduces the firmware register, KVM_REG_ARM_STD, which holds
the standard secure services (such as TRNG).
Patch-4 introduces the firmware register, KVM_REG_ARM_STD_HYP, which holds
the standard hypervisor services (such as PV_TIME).
Patch-5 introduces the firmware register, KVM_REG_ARM_VENDOR_HYP, which holds
the vendor specific hypercall services.
Patch-6 imports the firmware registers' UAPI definitions into tools/ for
further use in selftests.
Patch-7 imports the SMCCC definitions from linux/arm-smccc.h into tools/
for further use in selftests.
Patch-8 adds the selftest to test the guest (using 'hvc') and VMM
interfaces (SET/GET_ONE_REG).
[1]: https://lore.kernel.org/kvmarm/874kbcpmlq.wl-maz@xxxxxxxxxx/T/
[2]: https://lore.kernel.org/kvmarm/YUzgdbYk8BeCnHyW@xxxxxxxxxx/
Raghavendra Rao Ananta (8):
KVM: arm64: Factor out firmware register handling from psci.c
KVM: arm64: Setup base for hypercall firmware registers
KVM: arm64: Add standard secure service calls firmware register
KVM: arm64: Add standard hypervisor service calls firmware register
KVM: arm64: Add vendor hypervisor service calls firmware register
tools: Import the firmware registers
tools: Import ARM SMCCC definitions
selftests: KVM: aarch64: Introduce hypercall ABI test
.../virt/kvm/arm/{psci.rst => hypercalls.rst} | 59 ++-
Documentation/virt/kvm/arm/index.rst | 2 +-
arch/arm64/include/asm/kvm_host.h | 12 +
arch/arm64/include/uapi/asm/kvm.h | 18 +
arch/arm64/kvm/arm.c | 17 +
arch/arm64/kvm/guest.c | 2 +-
arch/arm64/kvm/hypercalls.c | 339 ++++++++++++++++-
arch/arm64/kvm/psci.c | 167 +--------
arch/arm64/kvm/pvtime.c | 3 +
arch/arm64/kvm/trng.c | 9 +-
include/kvm/arm_hypercalls.h | 18 +
include/kvm/arm_psci.h | 8 +-
tools/arch/arm64/include/uapi/asm/kvm.h | 18 +
tools/include/linux/arm-smccc.h | 188 ++++++++++
tools/testing/selftests/kvm/.gitignore | 1 +
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/aarch64/hypercalls.c | 340 ++++++++++++++++++
17 files changed, 1018 insertions(+), 184 deletions(-)
rename Documentation/virt/kvm/arm/{psci.rst => hypercalls.rst} (57%)
create mode 100644 tools/include/linux/arm-smccc.h
create mode 100644 tools/testing/selftests/kvm/aarch64/hypercalls.c
--
2.33.1.1089.g2158813163f-goog
