Hi Philippe,
On 18.01.26, 22:33, Philippe Mathieu-Daudé wrote:
> > These functions are needed for CPUs that support runtime-configurable
> > endianness.
> > In those cases, components such as semihosting need to perform
> > runtime-dependent byte swaps.
>
> Are you targetting user or system emulation?
>
> I suppose user emulation, otherwise you'd have used the
> "semihosting/uaccess.h" API.
>
> But then I'm confused because a user process can't change
> the CPU endianness...
>
> Can you explain your use case?
Thanks for asking! I am targeting system emulation. My use case is emulating
bare-metal software such as an OS that switches the AArch64 CPU to big-endian
mode during runtime.
`{get,set}_user_u{64,32}` from "semihosting/uaccess.h" currently use
`tswap{32,64}` from "exec/tswap.h", which do not respect runtime-configurable
endianness.
PATCH 1/2 introduces `cpu_tswap{32,64}`, which PATCH 2/2 integrates into
"semihosting/uaccess.h". I can squash those commits if you prefer, of course.
Or did I misunderstand your question?
Alex was worried about expanding the use of `virtio_is_big_endian`:
> Hmm looking at the description:
>
> /**
> * @virtio_is_big_endian: Callback to return %true if a CPU which supports
> * runtime configurable endianness is currently big-endian.
> * Non-configurable CPUs can use the default implementation of this
> method.
> * This method should not be used by any callers other than the pre-1.0
> * virtio devices.
> */
> bool (*virtio_is_big_endian)(CPUState *cpu);
>
> I'm not sure if we want to expand the usage of this hack. I think
> Philippe is hoping to get rid of these warts eventually. Of course we
> could rename the method and just provide a way to get the current
> systems endianess.
While not being very familiar with QEMU's source code, something like this
seems necessary to me. I can rename `virtio_is_big_endian` to `is_big_endian`
and `cpu_virtio_is_big_endian` to `cpu_is_big_endian` if you prefer that.
Cheers,
Martin
