Il dom 28 dic 2025, 17:00 Philippe Mathieu-Daudé <[email protected]> ha scritto:
> On 28/12/25 16:38, Paolo Bonzini wrote: > > > > > > Il dom 28 dic 2025, 16:14 Philippe Mathieu-Daudé <[email protected] > > <mailto:[email protected]>> ha scritto: > > > > > 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. > > > > > > The name is fine, the placement maybe a bit less; they could be moved > > out of bswap.h but it's not really necessary to do it now. > > Indeed not needed now, but already done to figure this API ;) This > helped me to understand what we don't need is "DO_STN_LDN_P(he)" > because this is a convoluted expansion to a plain memcpy(). > Without having seen your code, I will note that the simple conversion to memcpy() only works for little endian hosts. On big endian, you also need to adjust the first byte, like memcpy(p, ((uint8_t*)&val) + sizeof(val) - n, n); And likewise for ldn_he_p. (Apologize if you had noticed it, just trying to avoid a possible round trip over the holidays!) Paolo > > 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. > > > > > > Great, the other change I suggested was about the handling of MO_BSWAP > > but it can be done separately. > > This request is not ignored, but I plan to address it on top to keep > current changes simple enough. > > > > > If you don't want to repost and prefer to drop patch 14, we will also > > remove DEVICE_NATIVE_ENDIAN from subpages in a second step, for example > > by using "HOST_BIG_ENDIAN ? DEVICE_BIG_ENDIAN : DEVICE_LITTLE_ENDIAN" as > > in the ram_device ops. > > Yeah, that would even be smth like "DEVICE_ENDIANNESS_IS_IRRELEVANT", as > we call directly the ld/st_unaligned helpers. I'll think about that later. > >
