Hello everyone, we currently try to use/port libvirt to run on xenppc. While doing that I found a endianess issue. First a simple example: Sample code: #include <stdio.h> union u { int i; long long l; }; int main(void) { union u u; u.l = 0; u.i = ~0; printf("%016llx\n", u.l); return 0; } Little-endian output: 00000000ffffffff Big-endian output: ffffffff00000000 Now look at the padding in e.g. xen_v2s3_getdomaininfolistop: it doesn't work on big-endian systems. This problem is why the GUEST_HANDLE infrastructure is present in Xen. To work on big-endian systems, libvirt will need this or a similar mechanism. --- Current Questions --- We could now add several ugly ifdefs to libvirt code to differentiate powerpc from the others and solve the issue described above, but I think thats not a good solution. The GUEST_HANDLE mechanism would provide an architecture abstraction and is already implemented/working in libxc. The question is, shouldn't libvirt actually use the GUEST_HANDLE mechanism like libxc does (at least for the _v2d5_ structures) or are there big arguments against it? I would create a patch to add the GUEST_HANDLE stuff in libvirt if there is nothing against it, but I will need some help to test it on x86/x86_64/ia64 since I have no such machines here. If there is a major reason against the GUEST_HANDLE code, are there other suggestions/preferences how to solve this? Below is the technical background in a more verbose way for anyone interested --- Code Affected --- More or less everything in libvirt that would use GUEST_HANDLE in libxc: I saw the effect on a bad pointer passed down by the structure I use for my example below, but in the end it may affect all the stuff that uses the *GUEST_HANDLE* stuff in libxc which are e.g. uchar,ulong,... here an example: libxc: uint64_aligned_t max_pages; // <- arch dependent mapping of uint64_aligned_t libvirt: #define ALIGN_64 __attribute__((aligned(8))) uint64_t max_pages ALIGN_64; // <- this align is fix on all architectures --- The Issue in libvirt in one example --- XEN_GUEST_HANDLE usage in libxc: - XEN_GUEST_HANDLE is defined arch specific giving the arch the posibility to pad/align as needed. See xen/tools/libxc/xen/arch-powerpc.h for example. - xen/tools use set_xen_guest_handle and get_xen_guest_handle to set/access these handles and let the arch the posibility to handle any specific needs. Example: struct xen_sysctl_getdomaininfolist { domid_t first_domain; uint32_t max_domains; XEN_GUEST_HANDLE_64(xen_domctl_getdomaininfo_t) buffer; uint32_t num_domains; }; The arch defined XEN_GUEST_HANDLE_64 leads to the following type for buffer on powerpc (see the initial padding): typedef struct { \ int __pad[(sizeof (long long) - sizeof (void *)) / sizeof (int)]; \ xen_domctl_getdomaininfo_t *p; } __attribute__((__aligned__(8))) __guest_handle_xen_domctl_getdomaininfo_t In this scenario a 32bit pointer for *p with 0xFFFFFFFF will be stored as 0xPADPADPAFFFFFFFF and read in a valid way by the 64bit host that receives this syscall. XEN_GUEST_HANDLE usage in libvirt: - In my example where XEN_GUEST_HANDLE is in libxc libvirt currently uses a union based structure like the following: struct xen_v2s3_getdomaininfolistop { domid_t first_domain; uint32_t max_domains; union { struct xen_v2d5_getdomaininfo *v; uint64_t pad ALIGN_64; } buffer; uint32_t num_domains; }; typedef struct xen_v2s3_getdomaininfolistop xen_v2s3_getdomaininfolistop; The union used here to add the 64 bit padding does not work on big endian powerpc because reading this two half words in 64bit receiver gives 0xFFFFFFFF00000000 (The two half words are stored in the wrong order) while on ia64 it is read as the the valid 0x00000000FFFFFFFF. P.S. Thanks Hollis for the simple example code -- Grüsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization +49 7031/16-3385 Ehrhardt(a)linux.vnet.ibm.com Ehrhardt(a)de.ibm.com IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Johann Weihen Geschäftsführung: Herbert Kircher Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294