From: Salil Mehta <salil.mehta@huawei.com>
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Igor Mammedov <imammedo@redhat.com>,
"mst@redhat.com" <mst@redhat.com>
Subject: [Question] Regarding PMU initialization within the QEMU for ARM VCPUs
Date: Mon, 1 Jun 2020 15:04:33 +0000 [thread overview]
Message-ID: <b2e401cd17fe49d792d09b31bd726e35@huawei.com> (raw)
Hello,
I could see below within function fdt_add_pmu_nodes() part of
hw/arm/virt.c during virt machine initialization time:
Observation:
In below function, support of PMU feature is being checked for
each vcpu and if the PMU is found part of the features then PMU
is initialized with in the host/KVM. But if there is even one
vcpu which is found to not support the PMU then loop is exited
and PMU is not initialized for the rest of the vcpus as well.
static void fdt_add_pmu_nodes(const VirtMachineState *vms)
{
CPUState *cpu;
ARMCPU *armcpu;
uint32_t irqflags = GIC_FDT_IRQ_FLAGS_LEVEL_HI;
CPU_FOREACH(cpu) {
armcpu = ARM_CPU(cpu);
if (!arm_feature(&armcpu->env, ARM_FEATURE_PMU)) {
return; ------> Here, loop exits & function returns
}
if (kvm_enabled()) {
if (kvm_irqchip_in_kernel()) {
kvm_arm_pmu_set_irq(cpu, PPI(VIRTUAL_PMU_IRQ));
}
kvm_arm_pmu_init(cpu);
}
}
if (vms->gic_version == VIRT_GIC_VERSION_2) {
irqflags = deposit32(irqflags, GIC_FDT_IRQ_PPI_CPU_START,
GIC_FDT_IRQ_PPI_CPU_WIDTH,
(1 << vms->smp_cpus) - 1);
}
armcpu = ARM_CPU(qemu_get_cpu(0));
qemu_fdt_add_subnode(vms->fdt, "/pmu");
if (arm_feature(&armcpu->env, ARM_FEATURE_V8)) {
const char compat[] = "arm,armv8-pmuv3";
qemu_fdt_setprop(vms->fdt, "/pmu", "compatible",
compat, sizeof(compat));
qemu_fdt_setprop_cells(vms->fdt, "/pmu", "interrupts",
GIC_FDT_IRQ_TYPE_PPI, VIRTUAL_PMU_IRQ, irqflags);
}
}
Questions:
Q1. Not sure what is the logic of the premature exit and not
continuing with further checks and initialization of other
VCPU PMUs?
Q2. Does it even makes sense to have PMUs initialized for some
vcpus and not for others unless we have heterogeneous system?
Q3. Also, there is a per virt machine knob of vcc->no_pmu.
This is something which user could specify at the init time
and perhaps only once but we don't use it for ARM. Perhaps
should have been used even before entering this function
to enable or disable the support as per user config?
Q4. This function fdt_* looks to be wrongly named. The info
being initialized here shall be used even when ACPI is
being used. Initialization part and FDT info looked
mixed up here if I am right?
Best regards
Salil
next reply other threads:[~2020-06-01 15:05 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-01 15:04 Salil Mehta [this message]
2020-06-03 9:37 ` [Question] Regarding PMU initialization within the QEMU for ARM VCPUs Andrew Jones
2020-06-03 9:59 ` Auger Eric
2020-06-03 10:21 ` Andrew Jones
2020-06-03 11:39 ` Auger Eric
2020-06-05 15:24 ` Igor Mammedov
2020-06-03 11:50 ` Salil Mehta
2020-06-03 11:45 ` Salil Mehta
2020-06-03 12:16 ` Andrew Jones
2020-06-03 13:48 ` Salil Mehta
2020-06-03 14:36 ` Andrew Jones
2020-06-03 14:53 ` Salil Mehta
2020-06-05 15:31 ` Igor Mammedov
2020-06-05 16:38 ` Salil Mehta
2020-06-08 12:00 ` Igor Mammedov
2020-06-08 13:49 ` Salil Mehta
-- strict thread matches above, loose matches on Subject: below --
2020-06-03 8:38 Salil Mehta
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=b2e401cd17fe49d792d09b31bd726e35@huawei.com \
--to=salil.mehta@huawei.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--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).