qemu-devel
[Top][All Lists]
Advanced

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

Re: Status of some Arm features


From: Pierrick Bouvier
Subject: Re: Status of some Arm features
Date: Wed, 20 Nov 2024 15:48:16 -0800
User-agent: Mozilla Thunderbird

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




reply via email to

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