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@xxxxxxxxxxxxxxxxxx
Ehrhardt@xxxxxxxxxx
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Johann Weihen
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list