Re: Status of some Arm features

[Pierrick Bouvier <pierrick.bouvier@linaro.org>]

On 11/19/24 02:54, Peter Maydell wrote:
> On Tue, 19 Nov 2024 at 10:09, Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> On Mon, 18 Nov 2024 at 23:33, Pierrick Bouvier wrote:
>>> 8.4:
>>> - FEAT_CNTSC, Generic Counter Scaling (hw/timer/sse-counter.c)
>>
>> This is optional, and we don't implement it yet. (There's an
>> open ticket for it in Linaro JIRA at
>> https://linaro.atlassian.net/browse/QEMU-309 )
> 
> Oh, and I didn't notice you mentioning sse-counter.c here.
> That source file is for an M-profile device, which performs
> a similar function to but is not the same as the A-profile
> memory-mapped counter which FEAT_CNTSC is an extension for.
> 
> The A-profile memory-mapped counter is technically architecturally
> required but in practice none of the guest software we're
> running on the board models we implement cares about it.
> 
> We don't model the A-profile memory mapped counter, because
> so far we haven't had a real need to. Modelling this is not
> completely trivial, because in a system with the memory
> mapped architectural counter/timer modules, all the CPU
> generic timers (accessed via system registers) are supposed
> to take their source of time from the memory-mapped
> counter (and so for instance if you write to the memory mapped
> counter to stop it from counting then the CPU generic timers
> also must stop counting). So you need something similar to
> what I implemented in sse-counter.c where it provides an
> interface that other timer devices can use to consume its
> count (sse_counter_register_consumer(), sse_counter_for_timestamp(),
> sse_counter_tick_to_time() -- these are used by the M-profile
> hw/timer/sse-timer).
> 
> I do actually have a hacked-together prototype of this for
> A-profile that I did for something a while back, but it's not
> really in a state to be able to post upstream currently
> (I just did the bits I needed and didn't really finish it
> out or test it very much). So if we need this (e.g. if
> we decide it makes sense to implement in the sbsa-ref
> board) we could do it. But there doesn't really seem to
> be any requirement to do this work right now.
> 

Thanks for the insight Peter, it's very helpful to understand.

> -- PMM