From: Marc Zyngier <maz@kernel.org>
To: Sebastian Ene <sebastianene@google.com>
Cc: will@kernel.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Subject: Re: [PATCH kvmtool v7 2/3] aarch64: Add stolen time support
Date: Wed, 02 Mar 2022 14:41:07 +0000 [thread overview]
Message-ID: <8735k02z98.wl-maz@kernel.org> (raw)
In-Reply-To: <20220302140734.1015958-3-sebastianene@google.com>
Hi Sebastian,
On Wed, 02 Mar 2022 14:07:35 +0000,
Sebastian Ene <sebastianene@google.com> wrote:
>
> This patch adds support for stolen time by sharing a memory region
> with the guest which will be used by the hypervisor to store the stolen
> time information. Reserve a 64kb MMIO memory region after the RTC peripheral
> to be used by pvtime. The exact format of the structure stored by the
> hypervisor is described in the ARM DEN0057A document.
>
> Signed-off-by: Sebastian Ene <sebastianene@google.com>
> ---
> Makefile | 1 +
> arm/aarch64/arm-cpu.c | 2 +-
> arm/aarch64/include/kvm/kvm-cpu-arch.h | 1 +
> arm/aarch64/pvtime.c | 103 +++++++++++++++++++++++++
> arm/include/arm-common/kvm-arch.h | 6 +-
> include/kvm/kvm-config.h | 1 +
> 6 files changed, 112 insertions(+), 2 deletions(-)
> create mode 100644 arm/aarch64/pvtime.c
>
> diff --git a/Makefile b/Makefile
> index f251147..e9121dc 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -182,6 +182,7 @@ ifeq ($(ARCH), arm64)
> OBJS += arm/aarch64/arm-cpu.o
> OBJS += arm/aarch64/kvm-cpu.o
> OBJS += arm/aarch64/kvm.o
> + OBJS += arm/aarch64/pvtime.o
> ARCH_INCLUDE := $(HDRS_ARM_COMMON)
> ARCH_INCLUDE += -Iarm/aarch64/include
>
> diff --git a/arm/aarch64/arm-cpu.c b/arm/aarch64/arm-cpu.c
> index d7572b7..7e4a3c1 100644
> --- a/arm/aarch64/arm-cpu.c
> +++ b/arm/aarch64/arm-cpu.c
> @@ -22,7 +22,7 @@ static void generate_fdt_nodes(void *fdt, struct kvm *kvm)
> static int arm_cpu__vcpu_init(struct kvm_cpu *vcpu)
> {
> vcpu->generate_fdt_nodes = generate_fdt_nodes;
> - return 0;
> + return kvm_cpu__setup_pvtime(vcpu);
> }
>
> static struct kvm_arm_target target_generic_v8 = {
> diff --git a/arm/aarch64/include/kvm/kvm-cpu-arch.h b/arm/aarch64/include/kvm/kvm-cpu-arch.h
> index 8dfb82e..2b2c1ff 100644
> --- a/arm/aarch64/include/kvm/kvm-cpu-arch.h
> +++ b/arm/aarch64/include/kvm/kvm-cpu-arch.h
> @@ -19,5 +19,6 @@
>
> void kvm_cpu__select_features(struct kvm *kvm, struct kvm_vcpu_init *init);
> int kvm_cpu__configure_features(struct kvm_cpu *vcpu);
> +int kvm_cpu__setup_pvtime(struct kvm_cpu *vcpu);
>
> #endif /* KVM__KVM_CPU_ARCH_H */
> diff --git a/arm/aarch64/pvtime.c b/arm/aarch64/pvtime.c
> new file mode 100644
> index 0000000..fdde683
> --- /dev/null
> +++ b/arm/aarch64/pvtime.c
> @@ -0,0 +1,103 @@
> +#include "kvm/kvm.h"
> +#include "kvm/kvm-cpu.h"
> +#include "kvm/util.h"
> +
> +#include <linux/byteorder.h>
> +#include <linux/types.h>
> +
> +#define ARM_PVTIME_STRUCT_SIZE (64)
> +
> +struct pvtime_data_priv {
> + bool is_supported;
> + char *usr_mem;
Consider using void * for pointers that do not have any particular
semantics associated to them.
> +};
> +
> +static struct pvtime_data_priv pvtime_data = {
> + .is_supported = true,
> + .usr_mem = NULL
> +};
> +
> +static int pvtime__alloc_region(struct kvm *kvm)
> +{
> + char *mem;
> + int ret = 0;
> +
> + mem = mmap(NULL, ARM_PVTIME_MMIO_SIZE, PROT_RW,
I sort of object to the 'MMIO' part of the name. The spec is quite
clear that this should be normal memory. That's purely cosmetic, but
still a bit confusing.
> + MAP_ANON_NORESERVE, -1, 0);
> + if (mem == MAP_FAILED)
> + return -errno;
> +
> + ret = kvm__register_dev_mem(kvm, ARM_PVTIME_MMIO_BASE,
> + ARM_PVTIME_MMIO_SIZE, mem);
This, on the other side, is wrong. Since the pvtime pages are memory,
mapping them with device attributes will do the wrong thing (the
hypervisor will write to a cacheable mapping, and the guest will
bypass the cache due to the S2 override that you provide here).
kvm__register_ram() is more likely to lead to the behaviour you'd
expect.
> + if (ret) {
> + munmap(mem, ARM_PVTIME_MMIO_SIZE);
> + return ret;
> + }
> +
> + pvtime_data.usr_mem = mem;
> + return ret;
> +}
> +
> +static int pvtime__teardown_region(struct kvm *kvm)
> +{
> + if (pvtime_data.usr_mem == NULL)
> + return 0;
> +
> + kvm__destroy_mem(kvm, ARM_PVTIME_MMIO_BASE,
> + ARM_PVTIME_MMIO_SIZE, pvtime_data.usr_mem);
> + munmap(pvtime_data.usr_mem, ARM_PVTIME_MMIO_SIZE);
> + pvtime_data.usr_mem = NULL;
> + return 0;
> +}
> +
> +dev_exit(pvtime__teardown_region);
> +
> +int kvm_cpu__setup_pvtime(struct kvm_cpu *vcpu)
> +{
> + int ret;
> + bool has_stolen_time;
> + u64 pvtime_guest_addr = ARM_PVTIME_MMIO_BASE + vcpu->cpu_id *
> + ARM_PVTIME_STRUCT_SIZE;
> + struct kvm_config *kvm_cfg = NULL;
> + struct kvm_device_attr pvtime_attr = (struct kvm_device_attr) {
> + .group = KVM_ARM_VCPU_PVTIME_CTRL,
> + .addr = KVM_ARM_VCPU_PVTIME_IPA
> + };
> +
> + kvm_cfg = &vcpu->kvm->cfg;
> + if (kvm_cfg->no_pvtime)
> + return 0;
> +
> + if (!pvtime_data.is_supported)
> + return -ENOTSUP;
It is a bit odd to have this hard failure if running on a system that
doesn't have pvtime. It forces the user to alter their command-line,
which is a bit annoying. I'd rather have a soft-fail here.
> +
> + has_stolen_time = kvm__supports_extension(vcpu->kvm,
> + KVM_CAP_STEAL_TIME);
> + if (!has_stolen_time)
> + return 0;
> +
> + ret = ioctl(vcpu->vcpu_fd, KVM_HAS_DEVICE_ATTR, &pvtime_attr);
> + if (ret) {
> + perror("KVM_HAS_DEVICE_ATTR failed\n");
> + goto out_err;
> + }
> +
> + if (!pvtime_data.usr_mem) {
> + ret = pvtime__alloc_region(vcpu->kvm);
> + if (ret) {
> + perror("Failed allocating pvtime region\n");
> + goto out_err;
> + }
> + }
> +
> + pvtime_attr.addr = (u64)&pvtime_guest_addr;
> + ret = ioctl(vcpu->vcpu_fd, KVM_SET_DEVICE_ATTR, &pvtime_attr);
> + if (!ret)
> + return 0;
> +
> + perror("KVM_SET_DEVICE_ATTR failed\n");
> + pvtime__teardown_region(vcpu->kvm);
> +out_err:
> + pvtime_data.is_supported = false;
> + return ret;
> +}
> diff --git a/arm/include/arm-common/kvm-arch.h b/arm/include/arm-common/kvm-arch.h
> index c645ac0..3f82663 100644
> --- a/arm/include/arm-common/kvm-arch.h
> +++ b/arm/include/arm-common/kvm-arch.h
> @@ -15,7 +15,8 @@
> * | PCI |////| plat | | | | |
> * | I/O |////| MMIO: | Flash | virtio | GIC | PCI | DRAM
> * | space |////| UART, | | MMIO | | (AXI) |
> - * | |////| RTC | | | | |
> + * | |////| RTC, | | | | |
> + * | |////| PVTIME| | | | |
> * +-------+----+-------+-------+--------+-----+---------+---......
> */
>
> @@ -34,6 +35,9 @@
> #define ARM_RTC_MMIO_BASE (ARM_UART_MMIO_BASE + ARM_UART_MMIO_SIZE)
> #define ARM_RTC_MMIO_SIZE 0x10000
>
> +#define ARM_PVTIME_MMIO_BASE (ARM_RTC_MMIO_BASE + ARM_RTC_MMIO_SIZE)
> +#define ARM_PVTIME_MMIO_SIZE SZ_64K
> +
> #define KVM_FLASH_MMIO_BASE (ARM_MMIO_AREA + 0x1000000)
> #define KVM_FLASH_MAX_SIZE 0x1000000
>
> diff --git a/include/kvm/kvm-config.h b/include/kvm/kvm-config.h
> index 6a5720c..48adf27 100644
> --- a/include/kvm/kvm-config.h
> +++ b/include/kvm/kvm-config.h
> @@ -62,6 +62,7 @@ struct kvm_config {
> bool no_dhcp;
> bool ioport_debug;
> bool mmio_debug;
> + bool no_pvtime;
> };
>
> #endif
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Sebastian Ene <sebastianene@google.com>
Cc: kvm@vger.kernel.org, qperret@google.com,
kvmarm@lists.cs.columbia.edu, will@kernel.org,
julien.thierry.kdev@gmail.com
Subject: Re: [PATCH kvmtool v7 2/3] aarch64: Add stolen time support
Date: Wed, 02 Mar 2022 14:41:07 +0000 [thread overview]
Message-ID: <8735k02z98.wl-maz@kernel.org> (raw)
In-Reply-To: <20220302140734.1015958-3-sebastianene@google.com>
Hi Sebastian,
On Wed, 02 Mar 2022 14:07:35 +0000,
Sebastian Ene <sebastianene@google.com> wrote:
>
> This patch adds support for stolen time by sharing a memory region
> with the guest which will be used by the hypervisor to store the stolen
> time information. Reserve a 64kb MMIO memory region after the RTC peripheral
> to be used by pvtime. The exact format of the structure stored by the
> hypervisor is described in the ARM DEN0057A document.
>
> Signed-off-by: Sebastian Ene <sebastianene@google.com>
> ---
> Makefile | 1 +
> arm/aarch64/arm-cpu.c | 2 +-
> arm/aarch64/include/kvm/kvm-cpu-arch.h | 1 +
> arm/aarch64/pvtime.c | 103 +++++++++++++++++++++++++
> arm/include/arm-common/kvm-arch.h | 6 +-
> include/kvm/kvm-config.h | 1 +
> 6 files changed, 112 insertions(+), 2 deletions(-)
> create mode 100644 arm/aarch64/pvtime.c
>
> diff --git a/Makefile b/Makefile
> index f251147..e9121dc 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -182,6 +182,7 @@ ifeq ($(ARCH), arm64)
> OBJS += arm/aarch64/arm-cpu.o
> OBJS += arm/aarch64/kvm-cpu.o
> OBJS += arm/aarch64/kvm.o
> + OBJS += arm/aarch64/pvtime.o
> ARCH_INCLUDE := $(HDRS_ARM_COMMON)
> ARCH_INCLUDE += -Iarm/aarch64/include
>
> diff --git a/arm/aarch64/arm-cpu.c b/arm/aarch64/arm-cpu.c
> index d7572b7..7e4a3c1 100644
> --- a/arm/aarch64/arm-cpu.c
> +++ b/arm/aarch64/arm-cpu.c
> @@ -22,7 +22,7 @@ static void generate_fdt_nodes(void *fdt, struct kvm *kvm)
> static int arm_cpu__vcpu_init(struct kvm_cpu *vcpu)
> {
> vcpu->generate_fdt_nodes = generate_fdt_nodes;
> - return 0;
> + return kvm_cpu__setup_pvtime(vcpu);
> }
>
> static struct kvm_arm_target target_generic_v8 = {
> diff --git a/arm/aarch64/include/kvm/kvm-cpu-arch.h b/arm/aarch64/include/kvm/kvm-cpu-arch.h
> index 8dfb82e..2b2c1ff 100644
> --- a/arm/aarch64/include/kvm/kvm-cpu-arch.h
> +++ b/arm/aarch64/include/kvm/kvm-cpu-arch.h
> @@ -19,5 +19,6 @@
>
> void kvm_cpu__select_features(struct kvm *kvm, struct kvm_vcpu_init *init);
> int kvm_cpu__configure_features(struct kvm_cpu *vcpu);
> +int kvm_cpu__setup_pvtime(struct kvm_cpu *vcpu);
>
> #endif /* KVM__KVM_CPU_ARCH_H */
> diff --git a/arm/aarch64/pvtime.c b/arm/aarch64/pvtime.c
> new file mode 100644
> index 0000000..fdde683
> --- /dev/null
> +++ b/arm/aarch64/pvtime.c
> @@ -0,0 +1,103 @@
> +#include "kvm/kvm.h"
> +#include "kvm/kvm-cpu.h"
> +#include "kvm/util.h"
> +
> +#include <linux/byteorder.h>
> +#include <linux/types.h>
> +
> +#define ARM_PVTIME_STRUCT_SIZE (64)
> +
> +struct pvtime_data_priv {
> + bool is_supported;
> + char *usr_mem;
Consider using void * for pointers that do not have any particular
semantics associated to them.
> +};
> +
> +static struct pvtime_data_priv pvtime_data = {
> + .is_supported = true,
> + .usr_mem = NULL
> +};
> +
> +static int pvtime__alloc_region(struct kvm *kvm)
> +{
> + char *mem;
> + int ret = 0;
> +
> + mem = mmap(NULL, ARM_PVTIME_MMIO_SIZE, PROT_RW,
I sort of object to the 'MMIO' part of the name. The spec is quite
clear that this should be normal memory. That's purely cosmetic, but
still a bit confusing.
> + MAP_ANON_NORESERVE, -1, 0);
> + if (mem == MAP_FAILED)
> + return -errno;
> +
> + ret = kvm__register_dev_mem(kvm, ARM_PVTIME_MMIO_BASE,
> + ARM_PVTIME_MMIO_SIZE, mem);
This, on the other side, is wrong. Since the pvtime pages are memory,
mapping them with device attributes will do the wrong thing (the
hypervisor will write to a cacheable mapping, and the guest will
bypass the cache due to the S2 override that you provide here).
kvm__register_ram() is more likely to lead to the behaviour you'd
expect.
> + if (ret) {
> + munmap(mem, ARM_PVTIME_MMIO_SIZE);
> + return ret;
> + }
> +
> + pvtime_data.usr_mem = mem;
> + return ret;
> +}
> +
> +static int pvtime__teardown_region(struct kvm *kvm)
> +{
> + if (pvtime_data.usr_mem == NULL)
> + return 0;
> +
> + kvm__destroy_mem(kvm, ARM_PVTIME_MMIO_BASE,
> + ARM_PVTIME_MMIO_SIZE, pvtime_data.usr_mem);
> + munmap(pvtime_data.usr_mem, ARM_PVTIME_MMIO_SIZE);
> + pvtime_data.usr_mem = NULL;
> + return 0;
> +}
> +
> +dev_exit(pvtime__teardown_region);
> +
> +int kvm_cpu__setup_pvtime(struct kvm_cpu *vcpu)
> +{
> + int ret;
> + bool has_stolen_time;
> + u64 pvtime_guest_addr = ARM_PVTIME_MMIO_BASE + vcpu->cpu_id *
> + ARM_PVTIME_STRUCT_SIZE;
> + struct kvm_config *kvm_cfg = NULL;
> + struct kvm_device_attr pvtime_attr = (struct kvm_device_attr) {
> + .group = KVM_ARM_VCPU_PVTIME_CTRL,
> + .addr = KVM_ARM_VCPU_PVTIME_IPA
> + };
> +
> + kvm_cfg = &vcpu->kvm->cfg;
> + if (kvm_cfg->no_pvtime)
> + return 0;
> +
> + if (!pvtime_data.is_supported)
> + return -ENOTSUP;
It is a bit odd to have this hard failure if running on a system that
doesn't have pvtime. It forces the user to alter their command-line,
which is a bit annoying. I'd rather have a soft-fail here.
> +
> + has_stolen_time = kvm__supports_extension(vcpu->kvm,
> + KVM_CAP_STEAL_TIME);
> + if (!has_stolen_time)
> + return 0;
> +
> + ret = ioctl(vcpu->vcpu_fd, KVM_HAS_DEVICE_ATTR, &pvtime_attr);
> + if (ret) {
> + perror("KVM_HAS_DEVICE_ATTR failed\n");
> + goto out_err;
> + }
> +
> + if (!pvtime_data.usr_mem) {
> + ret = pvtime__alloc_region(vcpu->kvm);
> + if (ret) {
> + perror("Failed allocating pvtime region\n");
> + goto out_err;
> + }
> + }
> +
> + pvtime_attr.addr = (u64)&pvtime_guest_addr;
> + ret = ioctl(vcpu->vcpu_fd, KVM_SET_DEVICE_ATTR, &pvtime_attr);
> + if (!ret)
> + return 0;
> +
> + perror("KVM_SET_DEVICE_ATTR failed\n");
> + pvtime__teardown_region(vcpu->kvm);
> +out_err:
> + pvtime_data.is_supported = false;
> + return ret;
> +}
> diff --git a/arm/include/arm-common/kvm-arch.h b/arm/include/arm-common/kvm-arch.h
> index c645ac0..3f82663 100644
> --- a/arm/include/arm-common/kvm-arch.h
> +++ b/arm/include/arm-common/kvm-arch.h
> @@ -15,7 +15,8 @@
> * | PCI |////| plat | | | | |
> * | I/O |////| MMIO: | Flash | virtio | GIC | PCI | DRAM
> * | space |////| UART, | | MMIO | | (AXI) |
> - * | |////| RTC | | | | |
> + * | |////| RTC, | | | | |
> + * | |////| PVTIME| | | | |
> * +-------+----+-------+-------+--------+-----+---------+---......
> */
>
> @@ -34,6 +35,9 @@
> #define ARM_RTC_MMIO_BASE (ARM_UART_MMIO_BASE + ARM_UART_MMIO_SIZE)
> #define ARM_RTC_MMIO_SIZE 0x10000
>
> +#define ARM_PVTIME_MMIO_BASE (ARM_RTC_MMIO_BASE + ARM_RTC_MMIO_SIZE)
> +#define ARM_PVTIME_MMIO_SIZE SZ_64K
> +
> #define KVM_FLASH_MMIO_BASE (ARM_MMIO_AREA + 0x1000000)
> #define KVM_FLASH_MAX_SIZE 0x1000000
>
> diff --git a/include/kvm/kvm-config.h b/include/kvm/kvm-config.h
> index 6a5720c..48adf27 100644
> --- a/include/kvm/kvm-config.h
> +++ b/include/kvm/kvm-config.h
> @@ -62,6 +62,7 @@ struct kvm_config {
> bool no_dhcp;
> bool ioport_debug;
> bool mmio_debug;
> + bool no_pvtime;
> };
>
> #endif
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2022-03-02 14:41 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-02 14:07 [PATCH kvmtool v7 0/3] aarch64: Add stolen time support Sebastian Ene
2022-03-02 14:07 ` Sebastian Ene
2022-03-02 14:07 ` [PATCH kvmtool v7 1/3] aarch64: Populate the vCPU struct before target->init() Sebastian Ene
2022-03-02 14:07 ` Sebastian Ene
2022-03-02 14:21 ` Marc Zyngier
2022-03-02 14:21 ` Marc Zyngier
2022-03-02 14:07 ` [PATCH kvmtool v7 2/3] aarch64: Add stolen time support Sebastian Ene
2022-03-02 14:07 ` Sebastian Ene
2022-03-02 14:41 ` Marc Zyngier [this message]
2022-03-02 14:41 ` Marc Zyngier
2022-03-03 12:01 ` Sebastian Ene
2022-03-03 17:51 ` Marc Zyngier
2022-03-07 11:46 ` Sebastian Ene
2022-03-07 10:52 ` Alexandru Elisei
2022-03-07 10:52 ` Alexandru Elisei
2022-03-07 11:46 ` Alexandru Elisei
2022-03-07 11:46 ` Alexandru Elisei
2022-03-07 14:55 ` Sebastian Ene
2022-03-02 14:07 ` [PATCH kvmtool v7 3/3] Add --no-pvtime command line argument Sebastian Ene
2022-03-02 14:07 ` Sebastian Ene
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8735k02z98.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=sebastianene@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.