[Libvir] big-endian support for libvirt - introduce GUEST_HANDLE infrastructure ?

[Daniel Veillard]

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 at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/