qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 11/21] target-arm: Don't mention PMU in debug


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH v4 11/21] target-arm: Don't mention PMU in debug feature register
Date: Mon, 17 Mar 2014 23:11:27 +1000

On Mon, Mar 17, 2014 at 10:58 PM, Peter Maydell
<address@hidden> wrote:
> On 17 March 2014 05:13, Peter Crosthwaite <address@hidden> wrote:
>> On Fri, Mar 7, 2014 at 5:32 AM, Peter Maydell <address@hidden> wrote:
>>> Suppress the ID_AA64DFR0_EL1 PMUVer field, even if the CPU specific
>>> value claims that it exists. QEMU doesn't currently implement it,
>>> and not advertising it prevents the guest from trying to use it
>>> and getting UNDEFs on unimplemented registers.
>>>
>>> Signed-off-by: Peter Maydell <address@hidden>
>>
>> Reviewed-by: Peter Crosthwaite <address@hidden>
>>
>>> ---
>>> This is arguably a hack, but otherwise Linux tries to prod
>>> half a dozen PMU sysregs.
>>
>> Not really. I think sane self-identification trumps dummy feature
>> advertising. Although there is a consistency argument to be made, as
>> to whether you should also wipe-out any other features advertised by
>> this register and friends (e.g. should TraceVer be set?).
>
> The lack of consistency is what makes it a hack :-) Generally
> QEMU takes the approach of "report what the h/w reports even
> if we don't implement it all"; "report what we provide even
> if that's not the same values as h/w" would be a different
> approach, but if we wanted that we'd need to do it consistently.

I think there is an argument to decide it case by case ..

> Still I think pragmatism wins out here.
>

In cases where QEMU can validly nop the feature in question (like
caches etc.) then faking up to match real HW is cool. But if a guest
can take a feature advertisment then if() on it to bang on
non-existant hardware causing bus errors or exceptions then I think we
should remove the advertisements even if it is a deviation from real
hw register state. Supporting a good guest that has self identificaton
correct seems more worthwhile than support a guest that somehow
requires a feature advertisment without actually using the feature.

Regards,
Peter

> thanks
> -- PMM
>



reply via email to

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