qemu-arm
[Top][All Lists]
Advanced

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



reply via email to

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