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