Re: [Libvir] big-endian support for libvirt - introduce GUEST_HANDLE infrastructure ?
On Fri, Jul 06, 2007 at 11:06:54AM +0200, Christian Ehrhardt wrote:
Hello everyone,
we currently try to use/port libvirt to run on xenppc.
Hello, cool :-)
While doing that
I found a endianess issue.
less cool <grin/>
[...]
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.
Really ? I did a quick scan in xen_internal.c , that's the only place where
the problem might be raised, and found only 3 structure where the problem
was likely to occur: xen_v2s3_getdomaininfolistop, xen_v2d5_cpumap, and
xen_v2_setschedinfo, the two first ones clearly the last one is less clear.
Detecting big-endian vs. little can easilly be done in configure or inherited
from a system include and a couple of
struct xen_v2d5_cpumap {
#ifdef LITTLE_ENDIAN
union {
uint8_t *v;
uint64_t pad ALIGN_64;
} bitmap;
#else
struct {
uint8_t *pad;
uint8_t *v;
} bitmap;
#endif
uint32_t nr_cpus;
};
Might be easier to understand than the GUEST_HANDLE complex macros.
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'm not sure it helps on code maintainance, since it would affect
only a couple of places in libvirt. Also we definitely cannot copy
code from libxc due to licence incompatibilities, avoiding reusing
the exact same mechanism makes it even clearer it's a rewrite.
[...]
--- 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:
How many places in libvirt are really affected ? I count 3, we use a
very small subset of the hypercalls, but I may be wrong. If there is really
more places then maybe a macro based mechanism is better maintainance wise
but in any case it would have to be rewritten from scratch to avoid nervosity
from our Xensource friends.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/