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