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