Status of some Arm features

Status of some Arm features

[Pierrick Bouvier]

Hello,

I'm currently reviewing the QEMU Arm documentation, and I have a 
question about the status of following features:

8.0:
- FEAT_DoubleLock, Double Lock
8.2:
- FEAT_ASMv8p2, Armv8.2 changes to the A64 ISA (bfc and rev64 instructions)
8.4:
- FEAT_CNTSC, Generic Counter Scaling (hw/timer/sse-counter.c)

 From what I see, it seems like they are already implemented in QEMU. Is 
that correct?

Thanks,
Pierrick

Re: Status of some Arm features

[Peter Maydell]

On Mon, 18 Nov 2024 at 23:33, Pierrick Bouvier
<pierrick.bouvier@linaro.org> wrote:
> I'm currently reviewing the QEMU Arm documentation, and I have a
> question about the status of following features:
>
> 8.0:
> - FEAT_DoubleLock, Double Lock

This is actually an "anti-feature" :-)  It is optional from v8.0
and it must not be implemented from v9.0. We implement the handling
of it based on the DOUBLELOCK fields in ID_AA64DFR0 and DBGDEVID
(so it does the right thing on older named CPU types) and don't
advertise it in "max".

> 8.2:
> - FEAT_ASMv8p2, Armv8.2 changes to the A64 ISA (bfc and rev64 instructions)

This isn't a feature for CPU implementations; it's a feature for
assemblers and disassemblers, which have to recognize BFC and
REV64 mnemonics as being ways to write special-case flavours
of the BFM and REV instructions.

> 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 )

thanks
-- PMM

Re: Status of some Arm features

[Peter Maydell]

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.

-- PMM

Re: Status of some Arm features

[Pierrick Bouvier]

On 11/19/24 02:09, Peter Maydell wrote:
> On Mon, 18 Nov 2024 at 23:33, Pierrick Bouvier
> <pierrick.bouvier@linaro.org> wrote:
>> I'm currently reviewing the QEMU Arm documentation, and I have a
>> question about the status of following features:
>>
>> 8.0:
>> - FEAT_DoubleLock, Double Lock
> 
> This is actually an "anti-feature" :-)  It is optional from v8.0
> and it must not be implemented from v9.0. We implement the handling
> of it based on the DOUBLELOCK fields in ID_AA64DFR0 and DBGDEVID
> (so it does the right thing on older named CPU types) and don't
> advertise it in "max".
>

Despite this singularity on versions implementation, should we list that 
in our documentation?

>> 8.2:
>> - FEAT_ASMv8p2, Armv8.2 changes to the A64 ISA (bfc and rev64 instructions)
> 
> This isn't a feature for CPU implementations; it's a feature for
> assemblers and disassemblers, which have to recognize BFC and
> REV64 mnemonics as being ways to write special-case flavours
> of the BFM and REV instructions.
> 

Reading the feature description [1] or the A-profile manual:
FEAT_ASMv8p2 introduces the BFC instruction to the A64 instruction set 
as an alias of BFM. It also requires that the BFC instruction and the 
A64 pseudo-instruction REV64 are implemented by assemblers.

I understand it's both introducing the BFC instructions *and also* 
ensure that BFC and REV64 are implemented by assemblers.
Is my interpretation wrong?

[1] 
https://developer.arm.com/documentation/109697/2024_09/Feature-descriptions/The-Armv8-2-architecture-extension

It seems to be the only feature (through all versions >= 8.0) that 
describes something this way, so I'm a bit puzzled about.

>> 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 )
> 

Ok. For my personal knowledge, does the implementation in 
hw/timer/sse-counter.c is related to it?

> thanks
> -- PMM

Thanks,
Pierrick

Re: Status of some Arm features

[Peter Maydell]

On Tue, 19 Nov 2024 at 16:52, Pierrick Bouvier
<pierrick.bouvier@linaro.org> wrote:
>
> On 11/19/24 02:09, Peter Maydell wrote:
> > On Mon, 18 Nov 2024 at 23:33, Pierrick Bouvier
> > <pierrick.bouvier@linaro.org> wrote:
> >> I'm currently reviewing the QEMU Arm documentation, and I have a
> >> question about the status of following features:
> >>
> >> 8.0:
> >> - FEAT_DoubleLock, Double Lock
> >
> > This is actually an "anti-feature" :-)  It is optional from v8.0
> > and it must not be implemented from v9.0. We implement the handling
> > of it based on the DOUBLELOCK fields in ID_AA64DFR0 and DBGDEVID
> > (so it does the right thing on older named CPU types) and don't
> > advertise it in "max".
> >
>
> Despite this singularity on versions implementation, should we list that
> in our documentation?

Yeah, I think we reasonably could.

> >> 8.2:
> >> - FEAT_ASMv8p2, Armv8.2 changes to the A64 ISA (bfc and rev64 instructions)
> >
> > This isn't a feature for CPU implementations; it's a feature for
> > assemblers and disassemblers, which have to recognize BFC and
> > REV64 mnemonics as being ways to write special-case flavours
> > of the BFM and REV instructions.
> >
>
> Reading the feature description [1] or the A-profile manual:
> FEAT_ASMv8p2 introduces the BFC instruction to the A64 instruction set
> as an alias of BFM. It also requires that the BFC instruction and the
> A64 pseudo-instruction REV64 are implemented by assemblers.
>
> I understand it's both introducing the BFC instructions *and also*
> ensure that BFC and REV64 are implemented by assemblers.
> Is my interpretation wrong?

For an implementation, there is no BFC instruction. If you look
at the Arm ARM entry for BFC, it says "This instruction is an alias
of the BFM instruction", which means it exists only for
assemblers and disassemblers and assembly authors.
(And if you look at the BFM instruction, there is no subset of the
encoding that is gated on any feature; so there is no extra
behaviour of BFM that got added here.)

These "alias" instructions are there to make the assembly be
a bit easier to read. The only unusual thing about this alias
is that it wasn't in the architecture right from the start,
which I think is why it got a FEAT_ name: to flag up that
if you're writing asm or if you're an assembler author then
you need to do something here. But if you're creating an
implementation of a CPU, then there's nothing to do, because
you already implemented the handling of BFM as part of ARMv8.0.

For an example of an alias that was present from v8.0, look
at "MOV (to/from SP)". This is an "ADD (immediate)" instruction
under the hood, but you can write it in assembly source as
"MOV SP, Xn", and the assembler will put in the same bit pattern
as if you'd written "ADD SP, Xn, #0". In QEMU (or in a hardware
implementation) we don't need to do anything for "MOV SP, Xn",
because our implementation of "ADD (imm)" will catch it.

> >> 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 )
> >
>
> Ok. For my personal knowledge, does the implementation in
> hw/timer/sse-counter.c is related to it?

I elaborated a bit on that in my other email -- they're
doing a similar thing, but sse-counter.c is M-profile.

-- PMM

Re: Status of some Arm features

[Pierrick Bouvier]

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

Re: Status of some Arm features

[Pierrick Bouvier]

On 11/19/24 09:14, Peter Maydell wrote:
> On Tue, 19 Nov 2024 at 16:52, Pierrick Bouvier
> <pierrick.bouvier@linaro.org> wrote:
>>
>> On 11/19/24 02:09, Peter Maydell wrote:
>>> On Mon, 18 Nov 2024 at 23:33, Pierrick Bouvier
>>> <pierrick.bouvier@linaro.org> wrote:
>>>> I'm currently reviewing the QEMU Arm documentation, and I have a
>>>> question about the status of following features:
>>>>
>>>> 8.0:
>>>> - FEAT_DoubleLock, Double Lock
>>>
>>> This is actually an "anti-feature" :-)  It is optional from v8.0
>>> and it must not be implemented from v9.0. We implement the handling
>>> of it based on the DOUBLELOCK fields in ID_AA64DFR0 and DBGDEVID
>>> (so it does the right thing on older named CPU types) and don't
>>> advertise it in "max".
>>>
>>
>> Despite this singularity on versions implementation, should we list that
>> in our documentation?
> 
> Yeah, I think we reasonably could.
> 

I'll add it in my upcoming series then.

>>>> 8.2:
>>>> - FEAT_ASMv8p2, Armv8.2 changes to the A64 ISA (bfc and rev64 instructions)
>>>
>>> This isn't a feature for CPU implementations; it's a feature for
>>> assemblers and disassemblers, which have to recognize BFC and
>>> REV64 mnemonics as being ways to write special-case flavours
>>> of the BFM and REV instructions.
>>>
>>
>> Reading the feature description [1] or the A-profile manual:
>> FEAT_ASMv8p2 introduces the BFC instruction to the A64 instruction set
>> as an alias of BFM. It also requires that the BFC instruction and the
>> A64 pseudo-instruction REV64 are implemented by assemblers.
>>
>> I understand it's both introducing the BFC instructions *and also*
>> ensure that BFC and REV64 are implemented by assemblers.
>> Is my interpretation wrong?
> 
> For an implementation, there is no BFC instruction. If you look
> at the Arm ARM entry for BFC, it says "This instruction is an alias
> of the BFM instruction", which means it exists only for
> assemblers and disassemblers and assembly authors.
> (And if you look at the BFM instruction, there is no subset of the
> encoding that is gated on any feature; so there is no extra
> behaviour of BFM that got added here.)
> 

Thanks, I have been confused by the presence of BFCI and BFM 
instructions, making me think we implemented something specific.
It's more clear now.

> These "alias" instructions are there to make the assembly be
> a bit easier to read. The only unusual thing about this alias
> is that it wasn't in the architecture right from the start,
> which I think is why it got a FEAT_ name: to flag up that
> if you're writing asm or if you're an assembler author then
> you need to do something here. But if you're creating an
> implementation of a CPU, then there's nothing to do, because
> you already implemented the handling of BFM as part of ARMv8.0.
> 
> For an example of an alias that was present from v8.0, look
> at "MOV (to/from SP)". This is an "ADD (immediate)" instruction
> under the hood, but you can write it in assembly source as
> "MOV SP, Xn", and the assembler will put in the same bit pattern
> as if you'd written "ADD SP, Xn, #0". In QEMU (or in a hardware
> implementation) we don't need to do anything for "MOV SP, Xn",
> because our implementation of "ADD (imm)" will catch it.
>

Got it, thanks.

>>>> 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 )
>>>
>>
>> Ok. For my personal knowledge, does the implementation in
>> hw/timer/sse-counter.c is related to it?
> 
> I elaborated a bit on that in my other email -- they're
> doing a similar thing, but sse-counter.c is M-profile.
> 
> -- PMM