On Fri, 4 Oct 2024 at 17:22, Philippe Mathieu-Daudé <phi...@linaro.org> wrote:
>
> Introduce the CPUClass::is_big_endian() handler and its
> common default.
>
> Signed-off-by: Philippe Mathieu-Daudé <phi...@linaro.org>
> ---
> include/hw/core/cpu.h | 3 ++-
> hw/core/cpu-common.c | 7 +++++++
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
> index 04e9ad49968..22ef7a44e86 100644
> --- a/include/hw/core/cpu.h
> +++ b/include/hw/core/cpu.h
> @@ -150,6 +150,7 @@ struct CPUClass {
> ObjectClass *(*class_by_name)(const char *cpu_model);
> void (*parse_features)(const char *typename, char *str, Error **errp);
>
> + bool (*is_big_endian)(CPUState *cpu);
> bool (*has_work)(CPUState *cpu);
> int (*mmu_index)(CPUState *cpu, bool ifetch);
> int (*memory_rw_debug)(CPUState *cpu, vaddr addr,
What does this actually mean, though? Arm for instance
has multiple different kinds of "big-endian" depending
on the CPU: both BE32 and BE8, and data-endianness not
necessarily being the same as instruction-endianness.
This series doesn't introduce any users of this new API.
It's hard to say without seeing what the intended use is,
but I would expect that probably they would want to be testing
something else, depending on what they're trying to do.
It's pretty uncommon for anything out in the system to
want to know what endianness a runtime-configurable CPU
happens to be set to, because in real hardware a device
has no way to tell. (This is why cpu_virtio_is_big_endian()
is named the way it is -- to discourage anybody from trying
to use it outside the virtio devices where we need it for
legacy "the spec wasn't written thinking about endianness
very hard" reasons.)
thanks
-- PMM
