Christian Ehrhardt wrote:
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.
Understood.
--- 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?
I had a look at the GUEST_HANDLE code in libxc (specifically
arch-powerpc.h vs arch-x86_{32,64}.h) and it looks as if something like
this should go into libvirt. I would just be careful about copying the
code verbatim because libvirt & libxc are under slightly different licenses.
As for testing: we have no 64 bit PPC machines at all available for us
to use that I'm aware of. We have plenty of i386 & x86-64, and one or
two IA64 machines.
Thanks for your analysis.
Rich.
--
Emerging Technologies, Red Hat -
http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903