[Libvir] PATCH: support Xen 3.0.5

[Daniel Veillard]

On Thu, Apr 12, 2007 at 05:51:04PM +0100, Daniel P. Berrange wrote:
> On Thu, Apr 12, 2007 at 12:33:14PM -0400, Daniel Veillard wrote:
> > >   - The HVM SEXPR for configuring the VNC / SDL graphics is no longere
> > >     part of the (image) block. it now matches the PVFB graphics config
> > >     and is an explicit  (vfb)  block within the (devices) block.
> > >     So if xend_config_format >= 4 we use the new style config - this
> > >     is assuming upstream XenD is patched to increment xend_config_format
> > >     from 3 to 4 - I send a patch & am confident it will be applied
> > >     very shortly.
> > 
> >   you mean the patch will be in before 3.0.5 ?
> 
> It is already in xen-unstable staging tree.

  good :-)

> >  cool thanks, a few comments on the patch below
> > I suggest to commit this, wait for xen-3.0.5 to officially roll out and
> > then make a new libvirt release.
> 
> I'd like to see a release sooner than that - there's a number of nasty bugs
> in the networking stuff which causes the daemon to SEGV, and the iptables
> ruleset changes are pretty important to get out. For Fedora we're planning
> to ship a xen-3.0.5  pre-release in the next Fedora 7 test in anticipation
> of the Xen 3.0.5 GA being available RSN. It'd be nice to have a real libvirt
> build in that, rather than applying a huge number of patches.

  Okay, so before Fedora 7 deadline, which was like a few weeks ago ...
I will do my best :-)

> > The painful thing is regression tests, we don't really have a good answer
> > some of the entry points are tested by virt-manager but for example the CPU
> > affinity stuff is really uncommon, actually it took months before we found
> > an error in the last change of hypercalls.
> 
> Its possible to test the VCPU stuff with virsh - that's how I tested it against
> the new HV. I can test it against 3.0.3 in the same way when I have a minute.

  I was more thinking in term of a framework we could use to regression test...
Keeping all version of Xen/KVM/... may not be possible, but if we could
autodetect when make tests is run on a machine what is available and test
that subset this would ease global coverage.

> > > +
> > > +/* As of Hypervisor Call v2,  DomCtl v5 we are now 8-byte aligned
> > > +   even on 32-bit archs when dealing with uint64_t */
> > > +#define ALIGN_64 __attribute__((aligned(8)))
> > 
> >  I'm wondering, should we test for GCC version here and #error if not,
> > so that people who may compile with a different compiler may have a 
> > chance to catch potential problem here ?
> 
> In theory yes, but in practice the user is doomed anyway, because we already
> have 
> 
>    #include <xen/dom0_ops.h>
>    #include <xen/version.h>
>    #include <xen/xen.h>
>    #include <xen/linux/privcmd.h>
> 
> which are littered with __attribute__((aligned(8))) with no check for GCC.

  Okay :-)

> >   hehe, now if Xen headers exported a maximum number of domain that
> > would be be clean. I would be surprized if there wasn't a hardcoded limit
> > but I was unable to find one under /usr/include/xen headers ...
> 
> Welll domid_t  is a uint16_t, so that's  65,3556 guests total.

  good point. A bit high as the default, though
  65000 * sizeof(xen_getdomaininfolist)
 is not that much in case of weird error case.

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/