There is a singular user.  It's unlikely we'll gain a big-endian build of Xen,
but it's far more unlikely that bitfields will differ from main endianness.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Anthony PERARD <anthony.perard@vates.tech>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Julien Grall <julien@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
CC: Bertrand Marquis <bertrand.marquis@arm.com>
CC: Shawn Anastasio <sanastasio@raptorengineering.com>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
CC: Daniel P. Smith <dpsmith@apertussolutions.com>
CC: Lin Liu <lin.liu@citrix.com>

I'm tempted to simply drop the logic in maptrack_node.  If any big-endian
build of Xen came along, that's probably the least of it's worries.

v5:
 * New.
---
 xen/common/grant_table.c                  | 4 ++--
 xen/include/xen/byteorder/big_endian.h    | 3 ---
 xen/include/xen/byteorder/little_endian.h | 3 ---
 3 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 6c77867f8cdd..d6886ee74847 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -979,12 +979,12 @@ static struct active_grant_entry *grant_map_exists(const struct domain *ld,
 union maptrack_node {
     struct {
         /* Radix tree slot pointers use two of the bits. */
-#ifdef __BIG_ENDIAN_BITFIELD
+#ifdef __BIG_ENDIAN
         unsigned long _0 : 2;
 #endif
         unsigned long rd : BITS_PER_LONG / 2 - 1;
         unsigned long wr : BITS_PER_LONG / 2 - 1;
-#ifndef __BIG_ENDIAN_BITFIELD
+#ifndef __BIG_ENDIAN
         unsigned long _0 : 2;
 #endif
     } cnt;
diff --git a/xen/include/xen/byteorder/big_endian.h b/xen/include/xen/byteorder/big_endian.h
index ce395a17f64b..9cfb567d51d5 100644
--- a/xen/include/xen/byteorder/big_endian.h
+++ b/xen/include/xen/byteorder/big_endian.h
@@ -4,9 +4,6 @@
 #ifndef __BIG_ENDIAN
 #define __BIG_ENDIAN 4321
 #endif
-#ifndef __BIG_ENDIAN_BITFIELD
-#define __BIG_ENDIAN_BITFIELD
-#endif
 
 #include <xen/types.h>
 #include <xen/byteorder/swab.h>
diff --git a/xen/include/xen/byteorder/little_endian.h b/xen/include/xen/byteorder/little_endian.h
index 8b118afba5e3..96c80eab2b12 100644
--- a/xen/include/xen/byteorder/little_endian.h
+++ b/xen/include/xen/byteorder/little_endian.h
@@ -4,9 +4,6 @@
 #ifndef __LITTLE_ENDIAN
 #define __LITTLE_ENDIAN 1234
 #endif
-#ifndef __LITTLE_ENDIAN_BITFIELD
-#define __LITTLE_ENDIAN_BITFIELD
-#endif
 
 #include <xen/types.h>
 #include <xen/byteorder/swab.h>
-- 
2.39.5

On 28.03.2025 14:44, Andrew Cooper wrote:
> There is a singular user.  It's unlikely we'll gain a big-endian build of Xen,
> but it's far more unlikely that bitfields will differ from main endianness.

Just one point: While endian-ness in general is dictated by hardware, endian-
ness of bitfields is entirely a psABI thing, aiui. Hence tying both together
(beyond the latter defaulting to the former) doesn't seem quite appropriate
to me.

> I'm tempted to simply drop the logic in maptrack_node.  If any big-endian
> build of Xen came along, that's probably the least of it's worries.

As long as it's not obviously broken, I'd prefer to keep such. While it may
not be a primary worry, it's still one less of all the worries then.

Jan

On 31/03/2025 8:42 am, Jan Beulich wrote:
> On 28.03.2025 14:44, Andrew Cooper wrote:
>> There is a singular user.  It's unlikely we'll gain a big-endian build of Xen,
>> but it's far more unlikely that bitfields will differ from main endianness.
> Just one point: While endian-ness in general is dictated by hardware, endian-
> ness of bitfields is entirely a psABI thing, aiui. Hence tying both together
> (beyond the latter defaulting to the former) doesn't seem quite appropriate
> to me.
>
>> I'm tempted to simply drop the logic in maptrack_node.  If any big-endian
>> build of Xen came along, that's probably the least of it's worries.
> As long as it's not obviously broken, I'd prefer to keep such. While it may
> not be a primary worry, it's still one less of all the worries then.

Given the way patch 3 has ended up, this is easier to keep than in
earlier revisions.

Still, I think it's of very dubious utility.

~Andrew