[Libvir] PATCH: support Xen 3.0.5

[Daniel P. Berrange]

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.

> >   - The QEMU device model allows a user to specify multiple devices
> >     for the boot order, eg  'andc' to indicated 'floppy', 'network'
> >     'cdrom', 'disk'. We assumed it was a single letter only. I now
> >     serialize this into multiple <boot dev='XXX'/> elements, ordered
> >     according to priority. The XML -> SEXPR conversion allows the
> >     same.
> > 
> > 
> > I've tested all this on a 32-bit Dom0 running on 32-bit HV, and 64-bit HV,
> > but not tested a 64-bit Dom0 on 64-bit HV. I'm pretty sure it'll work,but
> > if anyone is runnning 64-on-64 please test this patch.
> 
>  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.

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

> > +
> > +/* 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.

> >  
> >      nbids = ret;
> > +    /* Can't possibly have more than 10,000 concurrent guests
> > +     * so limit how many times we try, to avoid increasing
> > +     * without bound & thus allocating all of system memory !
> > +     * XXX I'll regret this comment in a few years time ;-)
> > +     */
> 
>   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.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|