[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [PATCH V8 0/2] Add option to configure guest vPMU

From: Peter Maydell
Subject: Re: [Qemu-arm] [PATCH V8 0/2] Add option to configure guest vPMU
Date: Thu, 27 Oct 2016 18:15:37 +0100

On 27 October 2016 at 18:06, Wei Huang <address@hidden> wrote:
> On 10/27/2016 09:28 AM, Peter Maydell wrote:
>> On 26 October 2016 at 07:28, Wei Huang <address@hidden> wrote:
>>> This patchset adds a pmu=[on/off] option to enable/disable vPMU support
>>> for guest VM. There are several reasons to justify this option. First,
>>> vPMU can be problematic for cross-migration between different SoC as perf
>>> counters are architecture-dependent. It is more flexible to have an option
>>> to turn it on/off. Secondly this option matches the "pmu" option as
>>> supported in libvirt. To make sure backward compatible, a PMU-related
>>> property is added to mach-virt machine types.
>> (Sorry, sent this as a reply to the v7 patch; resending to
>> attach it to the right thread...)
>> So what actually are we defining as "the PMU exists" here?
> "PMU exists" means that PMUv3 presence can be detected and related
> driver can be loaded for guest VM:
> * For DT: perf_event.c checks the presence of "armv8-pmuv3" in DT and do
> armv8pmu_probe_pmu().
> * For ACPI: Jeremy Linton submitted an ACPI-based ARM driver for
> upstream. This can be loaded when "PMU exists" is detected.
> Link:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/415372.html
>> The PMU exists in ARMv7 and we do actually implement it
>> in TCG for v7 and v8 cores (though it is a minimal
>> architecturally-valid implementation which implements no events,
>> only the cycle counter).
> This option shouldn't affect the existing TCG implementation. It only
> touch the recent hardware-assisted vPMU implemented by Shannon. In other
> words, it adds an option for users to turn off Shannon's vPMU (for the
> reasons of migration compatibility, etc)

Right, but at the moment the commit message says there's no
PMU in TCG at all. What's missing that causes there not to be one?
(I think maybe we just don't report it in the feature register,
which might be a bug.)

>> Should the PMU registers in TCG which we currently provide on
>> any v7-and-better CPU be hung off ARM_FEATURE_PMU instead ?
>> (this would result in the behaviour of virt-2.6 for TCG
>> changing in that we stop providing the PMU when we did
>> before, but I guess that's OK.)
> So you want to disable cycle_count for TCG mode? Reading ARM doc, I
> think cycle_count is minimally required for ARM (correct me if I am
> wrong). Here is the description for PMCR.N bits:
> "Number of event counters. A RO field that indicates the number counters
> implemented. A value of 0b00000 in this field indicates that only the
> Cycle Count Register PMCCNTR_EL0 is implemented. The value of this field
> is the number of event counters implemented. This value is in the range
> of 0b00000 , in which case only the PMCCNTR_EL0 is  implemented, to
> 0b11111 , which indicates that the PMCCNTR_EL0 and 31 event counters are
> implemented."
> If we want to disable cycle_count, QEMU has to declare PMCR
> in-accessible, right?

The cycle counter is required if the PMU exists, but the whole PMU
is optional. If the user says 'pmu=off' then shouldn't we be
disabling the implementation in TCG?

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]