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@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