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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list