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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list