On 28/12/25 11:44, Paolo Bonzini wrote:
Il sab 27 dic 2025, 21:34 Philippe Mathieu-Daudé <[email protected]
<mailto:[email protected]>> ha scritto:
1/ we can not have "guest native" endianness in single binary
2/ host endianness is only useful with "guest native" one,
otherwise if you know the guest endianness, you can just
use an explicit cpu_to_$endian method.
Host endianness is useful when not talking to the guest at all—e.g. for
sockets or kernel APIs.
*_he_* functions are basically just memcpy in that they support
unaligned accesses; plus stn_he_p has the advantage of taking a value
unlike memcpy which takes a pointer.
I see.
Perhaps the source of the confusion is that they are in bswap.h but they
(quite obviously since it's host endianness) never swap?
Hmm, maybe not well named API then.
I felt confident it was coherent because, except the ATI single
one-line case [*] which I believe is not the best implementation,
the rest of my series proved this API is easily removable, the
resulting code ending easier to understand IMHO.
It's easily removable because most of the time accesses are in guest
endianness, or aligned, but the replacement for *_he_* functions is not
picking a specific endianness; it's a normal pointer store. These are
not super common but especially in hw/display/ you can find them.
stn_he_p is the right choice for ATI.
OK. Let's consider the following patches removed then:
- 03/25 system: Use explicit endianness in subpage_ops::read/write()
- 14/25 system: Use explicit endianness in ram_device::read/write()
- 16/25 system: Allow restricting legacy ld/st_he() 'native-endian' API
All the series I posted this week build fine without them.
