On Tue, 19 Nov 2024 at 10:09, Peter Maydell <peter.mayd...@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. -- PMM
