[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [Qemu-devel] [PATCH RFC 1/1] arm64: add an option to turn
From: |
Wei Huang |
Subject: |
Re: [Qemu-arm] [Qemu-devel] [PATCH RFC 1/1] arm64: add an option to turn on/off vpmu support |
Date: |
Sat, 13 Aug 2016 01:06:13 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 |
On 08/01/2016 08:32 AM, Peter Maydell wrote:
> On 1 August 2016 at 14:26, Andrea Bolognani <address@hidden> wrote:
>> On Mon, 2016-08-01 at 15:08 +0200, Andrew Jones wrote:
>>>> I'm not sure a warning is enough: if I start a guest and
>>>> explicitly ask for a PMU, I expect it to be there, or for
>>>> the guest not to start at all. How does x86 behave in this
>>>> regard?
>>>
>>> Peter had a good suggestion for this. We need to wrap the property
>>> addition in an arm_feature check like the has_el3 property. That will
>>> remove it from all cpu types that don't support it.
>>
>> Wouldn't that mean that you'd be unable to use
>>
>> -cpu foo,pmu=off
>>
>> if CPU model 'foo' doesn't support a PMU? I'd expect that
>> to work.
>
> The current precedent (has_el3) doesn't work like that: if
> foo isn't a CPU which can support EL3 then the property doesn't
> exist, and it's an error to try to set it.
V1 sent. I tried to follow everyone's advice. See the following:
* set default pmu=off
* like el3, add a new feature ARM_FEATURE_HOST_PMU
* "pmu" property becomes CPU dependent. Only cortex-a53/cortex-a57/host
under certain mode support this option
* change struct ARMCPU field name "has_pmu" ==> "has_host_pmu" because
IMO "has_pmu" is misleading
BTW answering Andrea's question above: "-cpu foo,pmu=off" won't be
allowed in this patch if CPU "foo" doesn't support host-backed PMU. QEMU
will fail to run in this case. Maybe this is what we want?
Thanks,
-Wei
>
> thanks
> -- PMM
>