From: Peter Maydell <peter.maydell@linaro.org>
To: Andrew Jones <drjones@redhat.com>
Cc: qemu-arm <qemu-arm@nongnu.org>, QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PATCH 3/3] hw/arm/virt: Implement kvm-steal-time
Date: Fri, 31 Jul 2020 15:54:07 +0100 [thread overview]
Message-ID: <CAFEAcA8h+6btvjvx=j5v7Gn12+bros_UgFScKHaWVxh0dmi-Qw@mail.gmail.com> (raw)
In-Reply-To: <20200711101033.47371-4-drjones@redhat.com>
On Sat, 11 Jul 2020 at 11:10, Andrew Jones <drjones@redhat.com> wrote:
> We add the kvm-steal-time CPU property and implement it for machvirt.
> A tiny bit of refactoring was also done to allow pmu and pvtime to
> use the same vcpu device helper functions.
>
> Signed-off-by: Andrew Jones <drjones@redhat.com>
Hi; I'm forwarding a couple of comments here from Beata,
(whose secondment with Linaro is coming to an end so she won't
have access to her Linaro email address to continue the conversation):
> static void virt_cpu_post_init(VirtMachineState *vms)
> {
> - bool aarch64, pmu;
> + bool aarch64, pmu, steal_time;
> CPUState *cpu;
>
> aarch64 = object_property_get_bool(OBJECT(first_cpu), "aarch64", NULL);
> pmu = object_property_get_bool(OBJECT(first_cpu), "pmu", NULL);
> + steal_time = object_property_get_bool(OBJECT(first_cpu),
> + "kvm-steal-time", NULL);
>
> if (kvm_enabled()) {
> + hwaddr pvtime_base = vms->memmap[VIRT_PVTIME].base;
> + hwaddr pvtime_size = vms->memmap[VIRT_PVTIME].size;
> +
> + if (steal_time) {
> + MemoryRegion *pvtime = g_new(MemoryRegion, 1);
> +
> + memory_region_init_ram(pvtime, NULL, "pvtime", pvtime_size, NULL);
> + memory_region_add_subregion(get_system_memory(), pvtime_base,
> + pvtime);
> + }
B: I'm not sure whether it wouldn't be useful to have the area
allocated with size determined by number of VCPUs instead of having
pre-defined size.
> + if (vmc->kvm_no_steal_time &&
> + object_property_find(cpuobj, "kvm-steal-time", NULL)) {
> + object_property_set_bool(cpuobj, false, "kvm-steal-time", NULL);
> + }
> +
> if (vmc->no_pmu && object_property_find(cpuobj, "pmu", NULL)) {
> object_property_set_bool(cpuobj, "pmu", false, NULL);
> }
> @@ -2528,6 +2558,7 @@ static void virt_machine_5_0_options(MachineClass *mc)
> mc->numa_mem_supported = true;
> vmc->acpi_expose_flash = true;
> mc->auto_enable_numa_with_memdev = false;
> + vmc->kvm_no_steal_time = true;
> }
> DEFINE_VIRT_MACHINE(5, 0)
>
> diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
> index 54bcf17afd35..b5153afedcdf 100644
> --- a/include/hw/arm/virt.h
> +++ b/include/hw/arm/virt.h
> @@ -80,6 +80,7 @@ enum {
> VIRT_PCDIMM_ACPI,
> VIRT_ACPI_GED,
> VIRT_NVDIMM_ACPI,
> + VIRT_PVTIME,
> VIRT_LOWMEMMAP_LAST,
> };
>
> @@ -126,6 +127,7 @@ typedef struct {
> bool no_ged; /* Machines < 4.2 has no support for ACPI GED device */
> bool kvm_no_adjvtime;
> bool acpi_expose_flash;
> + bool kvm_no_steal_time;
B: It is slightly confusing : using kvm_no_steal_time vs kvm_steal_time
P: I have to admit I get confused about which sense this flag
should have. I think the sense of the flags in this struct is
"the false case is the one that the older virt boards had",
so original virt didn't have an ITS or a PMU and so we have
no_its and no_pmu. Similarly here old virt didn't have steal-time
and so we want a no_ flag (ie the patch is correct). Why
kvm_no_steal_time rather than no_kvm_steal_time, though ?
> } VirtMachineClass;
> +void kvm_arm_pvtime_init(CPUState *cs, uint64_t ipa)
> +{
> + struct kvm_device_attr attr = {
> + .group = KVM_ARM_VCPU_PVTIME_CTRL,
> + .attr = KVM_ARM_VCPU_PVTIME_IPA,
> + .addr = (uint64_t)&ipa,
> + };
> +
> + if (!ARM_CPU(cs)->kvm_steal_time) {
> + return;
> + }
> + if (!kvm_arm_set_device_attr(cs, &attr, "PVTIME IPA")) {
> + error_report("failed to init PVTIME IPA");
> + abort();
> + }
> +}
B: I am probably missing smth but .. there is a trigger missing to
update the stats
and write them back to pre-allocated guest memory.
Looking at the kernel code the stats are updated upon pending
VCPU request :
in arch/arm64/kvm/arm.c:
static void check_vcpu_requests(struct kvm_vcpu *vcpu) {
...
if (kvm_check_request(KVM_REQ_RECORD_STEAL, vcpu))
kvm_update_stolen_time(vcpu);
}
thanks
-- PMM
next prev parent reply other threads:[~2020-07-31 14:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-11 10:10 [PATCH 0/3] hw/arm/virt: Introduce kvm-steal-time Andrew Jones
2020-07-11 10:10 ` [PATCH 1/3] hw/arm/virt: Move post cpu realize check into its own function Andrew Jones
2020-07-21 10:03 ` Peter Maydell
2020-07-11 10:10 ` [PATCH 2/3] hw/arm/virt: Move kvm pmu setup to virt_cpu_post_init Andrew Jones
2020-07-21 10:02 ` Peter Maydell
2020-07-29 13:51 ` Andrew Jones
2020-07-11 10:10 ` [PATCH 3/3] hw/arm/virt: Implement kvm-steal-time Andrew Jones
2020-07-21 10:46 ` Peter Maydell
2020-07-29 14:40 ` Andrew Jones
2020-08-03 15:18 ` Andrew Jones
2020-07-31 14:54 ` Peter Maydell [this message]
2020-08-01 12:00 ` Andrew Jones
2020-08-03 15:16 ` Andrew Jones
2020-07-20 10:16 ` [PATCH 0/3] hw/arm/virt: Introduce kvm-steal-time Peter Maydell
2020-07-27 8:33 ` Andrew Jones
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='CAFEAcA8h+6btvjvx=j5v7Gn12+bros_UgFScKHaWVxh0dmi-Qw@mail.gmail.com' \
--to=peter.maydell@linaro.org \
--cc=drjones@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).