[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
>
[Qemu-devel] [PATCH v4 14/21] target-arm: Implement AArch64 views of fault status and data registers, Peter Maydell, 2014/03/06
[Qemu-devel] [PATCH v4 01/21] target-arm: Split out private-to-target functions into internals.h, Peter Maydell, 2014/03/06