[Top][All Lists]

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

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

From: Wei Huang
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH V8 0/2] Add option to configure guest vPMU
Date: Thu, 27 Oct 2016 15:53:16 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

On 10/27/2016 12:15 PM, Peter Maydell wrote:
> 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.)

This sounds like a bug (or incomplete). In current version of QEMU, if I
forced vPMU declaration in the feature register under TCG mode, PMU
driver will be loaded in VM. But as soon as "perf stat" is executed,
guest VM panic. I think some features, like PMU IRQ, is still missing
for TCG to turn vPMU on. I will debug it further.

>>> 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?

Let me clarify. Assuming we can get TCG mode to support VM's PMU driver
(see discussion above, only cycle counter supported for TCG), will the
following be sufficient?
(1) ,pmu=on
perf driver can be loaded in VM, and "perf" command can use HW counters
to profile.
(2) ,pmu=off
perf feature can't be detected, so the perf driver can't be loaded
inside VM. "perf" can't use HW perf counters. But PMU registers (PMCR,
PMCCNTR, ...) can still be accessed inside VM.


You prefer to disable access permission for PMU registers in (2). Note:
this is very strict. I am not sure if current KVM already follows this rule.

> thanks
> -- PMM

reply via email to

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