[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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 {
    union {
        uint8_t    *v;
        uint64_t   pad ALIGN_64;
    } bitmap;
    struct {
        uint8_t    *pad;
        uint8_t    *v;
    } bitmap;
    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.


Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]