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

[Daniel Veillard]

On Tue, Jul 10, 2007 at 02:02:19PM +0200, Christian Ehrhardt wrote:
> 
> >  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
> >
> >  
> Thats right - after looking around more in detail I also see not more 
> than the listed places at the moment.
> I did not expect that it is only such a small subset, but it is good 
> that way in reference to the current issue ;-)

  yeah, the scope of the troubles is limited. Future needs to use the hypercall
could be for example for more fine grained monitoring/profiling, but I don't
expect to add much in a near future. Next step in term of functionality is 
clearly migration but that will go though xend, not the hypervisor.

> >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.
> >
> >  
> [...]
> >  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.
> >  
> You are right, for the moment it is really sufficient to fix 
> xen_v2s3_getdomaininfolistop and xen_v2d5_cpumap.

  Good :-)

> I'll do something that way dependent on configure&ifdef and send a patch 
> (low prio since we have a workaround in the kernel)

  That would be perfect ! Maybe we don't even need to hook in configure
I'm sure endianness info can come from standard headers, then combined
with a processor check that should be sufficient I guess.

> BTW here is a short status which libvirt functions are working on xenppc 
> as seen on my first sniff test:
> working
>     *monitor load
>     *remove network interface
>     *remove hard disk
>     *access serial console
>     *define existing xen domains from/to xml file
>     *run/shutdown domains

  okay

> partially working
>     *add network device (work but cause a libvirt trace&hang afterwards)
>     *add hard disk (work but cause a libvirt trace&hang afterwards)

  weird, we are actually calling xend for this, that should not be platform
specific, could be an hidden generic bug

> not working
>     *sometimes xend hangs and only /etc/init.d/xend restart helps, 
> there are related tracebacks in xend.log

  that's libvirt related ?

>     *change number of cpu's

  hum, we do lot of bitfield operations there, there is certainly some cleanups
needed, so that's not surprizing

>     *create virtual network

  could be the calls to brctl or the iptable interfaces, some debugging 
certainly needed.

  Thanks a lot for the feedback, and don't hesitate to ask !

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/