8:46 p.m.
I've been doing some testing with current xen-unstable (ie what will very
shortly be 3.0.5) and came across a whole bunch of things which needed
fixing - some expected, others not expected. The attached patch addresses
the following issues:
- Many of the hypercalls have their structs changed so that int64_t
or 'foo *' members are always 64-bit aligned even on 32-bit platforms.
This is part of the work to allow 32-bit Dom0/DomU to work on 64-bit
hypervisor.
For the int64_t types I had to annotate with __attribute__((aligned(8))).
This did not work for pointer data types, so I for those I had to do
a more complex hack with
union {
foo *v;
int64_t pad __attribute__((aligned(8)))
}
This matches what is done in the public (BSD licensed) Xen HV header
files.
We already had ways to deal with v0 vs v2 hypercalls structs. This
change is still techincally v2, but just a minor revision of the
domctl or sysctl interfaces. Thus I have named the extra structs
v2d5 or v2s3 to indicated hypercall version 2, domctl version 5
or hypercall version 2, sysctl version 3 respectively.
- The 'flags' field in the getdomaininfo hypercall now has an extra flag
defined '(1<<1)' which was previously not used, is now used to indicate
that the guest is HVM. Thus when fetching domain state, we have to mask
out that flag, otherwise we'll never match the correct paused/running/
blocked/etc states.
- In the xenHypervisorNumOfDomains method, under certain scenarios we
will re-try the hypercall, allocating a bigger memory buffer. Well
due to the ABI alignment changes we hit that scenario everytime, and
ended up allocating a multi-GB buffer :-) The fixed structs sort this
out, but as a preventative measure for any future HV changes the patch
will break out of the loop at the 10,000 guest mark to avoid allocating
GB of memory.
- The unified Xen driver broke the GetVCPUs method - it was mistakenly
checking for return value == 0, instead of > 0. Trivial fix.
- The method to open the XenD connection was calling xenDaemonGetVersion
to test if the connection succeeded. But then also calling the
xend_detect_config_version which does pretty much same thing. So I
removed the former, and now we only do the latter as a 'ping' test
when opening. This removes 1 HTTP GET which is worthwhile performance
boost given how horrifically slow XenD is.
- 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.
- 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.
Regards,
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 -=|
8:56 p.m.
Hi, Dan
Thank you for submitting patch!
I am eased to see this. Since I can test on current xen-unstable.
Anyway I will test on with this patch.
Thanks
Atsushi SAKAI
"Daniel P. Berrange" <berrange(a)redhat.com> wrote:
I've been doing some testing with current xen-unstable (ie what
will very
shortly be 3.0.5) and came across a whole bunch of things which needed
fixing - some expected, others not expected. The attached patch addresses
the following issues:
- Many of the hypercalls have their structs changed so that int64_t
or 'foo *' members are always 64-bit aligned even on 32-bit platforms.
This is part of the work to allow 32-bit Dom0/DomU to work on 64-bit
hypervisor.
For the int64_t types I had to annotate with __attribute__((aligned(8))).
This did not work for pointer data types, so I for those I had to do
a more complex hack with
union {
foo *v;
int64_t pad __attribute__((aligned(8)))
}
This matches what is done in the public (BSD licensed) Xen HV header
files.
We already had ways to deal with v0 vs v2 hypercalls structs. This
change is still techincally v2, but just a minor revision of the
domctl or sysctl interfaces. Thus I have named the extra structs
v2d5 or v2s3 to indicated hypercall version 2, domctl version 5
or hypercall version 2, sysctl version 3 respectively.
- The 'flags' field in the getdomaininfo hypercall now has an extra flag
defined '(1<<1)' which was previously not used, is now used to
indicate
that the guest is HVM. Thus when fetching domain state, we have to mask
out that flag, otherwise we'll never match the correct paused/running/
blocked/etc states.
- In the xenHypervisorNumOfDomains method, under certain scenarios we
will re-try the hypercall, allocating a bigger memory buffer. Well
due to the ABI alignment changes we hit that scenario everytime, and
ended up allocating a multi-GB buffer :-) The fixed structs sort this
out, but as a preventative measure for any future HV changes the patch
will break out of the loop at the 10,000 guest mark to avoid allocating
GB of memory.
- The unified Xen driver broke the GetVCPUs method - it was mistakenly
checking for return value == 0, instead of > 0. Trivial fix.
- The method to open the XenD connection was calling xenDaemonGetVersion
to test if the connection succeeded. But then also calling the
xend_detect_config_version which does pretty much same thing. So I
removed the former, and now we only do the latter as a 'ping' test
when opening. This removes 1 HTTP GET which is worthwhile performance
boost given how horrifically slow XenD is.
- 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.
- 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.
Regards,
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 -=|
9:02 p.m.
On Thu, Apr 12, 2007 at 10:56:32AM +0900, Atsushi SAKAI wrote:
Hi, Dan
Thank you for submitting patch!
I am eased to see this. Since I can test on current xen-unstable.
Anyway I will test on with this patch.
Great. FYI - we're actively working on trying to get Fedora 7 rawhide updated
to xen-unstable, with the plan to have Fedora 7 GA on Xen 3.0.5. The timing
is really tight, but I'm hopeful we'll manage it. Xen 3.0.4 proving very
unstable, particularly in its userspace so we really want 3.0.5 if possible.
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 -=|
4:02 a.m.
A Man Without A Country Daniel P. Berrange wrote:
I've been doing some testing with current xen-unstable (ie what
will very
shortly be 3.0.5) and came across a whole bunch of things which needed
fixing - some expected, others not expected. The attached patch addresses
the following issues:
As a general question about policy, are we going to support every rev of
the HV interface? If Xen change the interface again before 3.0.5 will
we support this "pre-3.0.5" and the final interface?
- Many of the hypercalls have their structs changed so that
int64_t
or 'foo *' members are always 64-bit aligned even on 32-bit platforms.
This is part of the work to allow 32-bit Dom0/DomU to work on 64-bit
hypervisor.
For the int64_t types I had to annotate with __attribute__((aligned(8))).
This did not work for pointer data types, so I for those I had to do
a more complex hack with
union {
foo *v;
int64_t pad __attribute__((aligned(8)))
}
What is the problem here? I did some tests and it seems to work just fine:
/* Test alignment of pointers.
* Richard Jones <rjones~at~redhat~dot~com>
*/
#include <stdio.h>
#undef offsetof
#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
struct s {
char c;
//int v;
//int v __attribute__((aligned(16)));
int *v __attribute__((aligned(16)));
//struct s *v __attribute__((aligned(16)));
};
int
main ()
{
printf ("offset = %d\n", offsetof (struct s, v));
return 0;
}
$ gcc -Wall -Werror align.c -o align
$ ./align
offset = 16
$ arch
i686
$ gcc --version
gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)
Copyright (C) 2003 Free Software Foundation, Inc. [etc]
- The unified Xen driver broke the GetVCPUs method - it was
mistakenly
checking for return value == 0, instead of > 0. Trivial fix.
Ooops.
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.
I don't have 3.0.5 to test here, but I can possibly test this on Monday.
In the meantime I eyeballed the patch and from what I can tell it
seems fine.
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.
Registered in England and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David
Owens (Ireland)
8:50 a.m.
On Thu, Apr 12, 2007 at 10:02:45AM +0100, Richard W.M. Jones wrote:
A Man Without A Country Daniel P. Berrange wrote:
>I've been doing some testing with current xen-unstable (ie what will very
>shortly be 3.0.5) and came across a whole bunch of things which needed
>fixing - some expected, others not expected. The attached patch addresses
>the following issues:
As a general question about policy, are we going to support every rev of
the HV interface? If Xen change the interface again before 3.0.5 will
we support this "pre-3.0.5" and the final interface?
Yeah we aim to support pretty much all HV versions in 3.0.x It isn't actually
as bad as it sounds. In v2 of the hypercall ABI, there have been 3 revisions
of the sysctl ABI, and 5 of the domctl ABI. For the limited set of hypercalls
that libvirt makes though, there were no changes in domctl 1->4, or in the
sysctl 1->2. So we only need 2 code branches to deal with those 5 revisions
of the ABI.
> - Many of the hypercalls have their structs changed so that int64_t
> or 'foo *' members are always 64-bit aligned even on 32-bit platforms.
> This is part of the work to allow 32-bit Dom0/DomU to work on 64-bit
> hypervisor.
>
> For the int64_t types I had to annotate with
> __attribute__((aligned(8))).
> This did not work for pointer data types, so I for those I had to do
> a more complex hack with
>
> union {
> foo *v;
> int64_t pad __attribute__((aligned(8)))
> }
What is the problem here? I did some tests and it seems to work just fine:
I'm not sure - all I know is that it didn't work - all I got back from the
hypervisor was complete garbage. I will try it again, but I'm not hopeful
and its near impossible to debug.
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 -=|
11:33 a.m.
On Thu, Apr 12, 2007 at 02:46:46AM +0100, Daniel P. Berrange wrote:
I've been doing some testing with current xen-unstable (ie what
will very
shortly be 3.0.5) and came across a whole bunch of things which needed
fixing - some expected, others not expected. The attached patch addresses
the following issues:
Okay, thanks a lot for this !
- Many of the hypercalls have their structs changed so that
int64_t
or 'foo *' members are always 64-bit aligned even on 32-bit platforms.
This is part of the work to allow 32-bit Dom0/DomU to work on 64-bit
hypervisor.
For the int64_t types I had to annotate with __attribute__((aligned(8))).
This did not work for pointer data types, so I for those I had to do
a more complex hack with
union {
foo *v;
int64_t pad __attribute__((aligned(8)))
}
This matches what is done in the public (BSD licensed) Xen HV header
files.
We already had ways to deal with v0 vs v2 hypercalls structs. This
change is still techincally v2, but just a minor revision of the
domctl or sysctl interfaces. Thus I have named the extra structs
v2d5 or v2s3 to indicated hypercall version 2, domctl version 5
or hypercall version 2, sysctl version 3 respectively.
Though not completely see xen_op_v2_dom remark below
- The 'flags' field in the getdomaininfo hypercall now has
an extra flag
defined '(1<<1)' which was previously not used, is now used to
indicate
that the guest is HVM. Thus when fetching domain state, we have to mask
out that flag, otherwise we'll never match the correct paused/running/
blocked/etc states.
<grin/>
- In the xenHypervisorNumOfDomains method, under certain scenarios
we
will re-try the hypercall, allocating a bigger memory buffer. Well
due to the ABI alignment changes we hit that scenario everytime, and
ended up allocating a multi-GB buffer :-) The fixed structs sort this
out, but as a preventative measure for any future HV changes the patch
will break out of the loop at the 10,000 guest mark to avoid allocating
GB of memory.
That was a bug on our side :-)
- The unified Xen driver broke the GetVCPUs method - it was
mistakenly
That too !
- The method to open the XenD connection was calling
xenDaemonGetVersion
to test if the connection succeeded. But then also calling the
xend_detect_config_version which does pretty much same thing. So I
removed the former, and now we only do the latter as a 'ping' test
when opening. This removes 1 HTTP GET which is worthwhile performance
boost given how horrifically slow XenD is.
Good catch, I guess the detection was done only in one of the pre-driver code
then it was cleaned up, and the test was added at connection open time, but
unfortunately wasn't removed in the latter case, bug++
- 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 ?
- 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.
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.
From a patch perspective I feel relatively safe that this won't break
with the older hypervisor, but getting to actually testing it doesn't look
fun at all.
[...]
+
+/* 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 ?
@@ -415,10 +508,14 @@ struct xen_op_v2_dom {
domid_t domain;
union {
xen_v2_setmaxmem setmaxmem;
+ xen_v2d5_setmaxmem setmaxmemd5;
xen_v2_setmaxvcpu setmaxvcpu;
xen_v2_setvcpumap setvcpumap;
+ xen_v2d5_setvcpumap setvcpumapd5;
xen_v2_vcpuinfo getvcpuinfo;
+ xen_v2d5_vcpuinfo getvcpuinfod5;
xen_v2_getvcpumap getvcpumap;
+ xen_v2d5_getvcpumap getvcpumapd5;
uint8_t padding[128];
} u;
};
I was a bit surprized by that, somehow I was expecting
different struct xen_op_v2_dom and struct xen_op_v2d5_dom
but that allows to minimize the change and only the fields
in the union are impacted so that's probably better, yes.
@@ -1802,10 +1949,18 @@ xenHypervisorNumOfDomains(virConnectPtr
return (-1);
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 ...
if (nbids == maxids) {
- last_maxids *= 2;
- maxids *= 2;
- goto retry;
+ if (maxids < 10000) {
+ last_maxids *= 2;
+ maxids *= 2;
+ goto retry;
+ }
+ nbids = -1;
}
if ((nbids < 0) || (nbids > maxids))
return(-1);
I tried to look for other places where we may grow/realloc data like that
in the code, but apparently that's the only place, maybe except some
buffer handling but that looked safe, not as a loop like this !
@@ -1994,7 +2149,8 @@ xenHypervisorGetDomInfo(virConnectPtr co
return (-1);
domain_flags = XEN_GETDOMAININFO_FLAGS(dominfo);
- domain_state = domain_flags & 0xFF;
+ domain_flags &= ~DOMFLAGS_HVM; /* Mask out HVM flags */
+ domain_state = domain_flags & 0xFF; /* Mask out high bits */
switch (domain_state) {
case DOMFLAGS_DYING:
info->state = VIR_DOMAIN_SHUTDOWN;
<regrin/>
thanks again, please apply,
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
11:51 a.m.
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 -=|
2:06 p.m.
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
12:37 a.m.
Hi, Dan
I test on Fedora7 test3 x86_64 but failed.
(Old version(which includes test3) works fine.)
virsh dominfo 0
libvir: error : no support for hypervisor (null)
lt-virsh: error: failed to connect to the hypervisor
Thanks
Atsushi SAKAI
2:54 a.m.
On Fri, Apr 13, 2007 at 02:37:03PM +0900, Atsushi SAKAI wrote:
Hi, Dan
I test on Fedora7 test3 x86_64 but failed.
(Old version(which includes test3) works fine.)
virsh dominfo 0
libvir: error : no support for hypervisor (null)
lt-virsh: error: failed to connect to the hypervisor
Hi Atsushi,
could you help us a bit with the debugging there, by running as root
lt-virsh under gdb and adding a breakpoint in xenHypervisorInit()
around line 1233 in xen_internal.c the version detection starts.
We test a couple of hypervisor call here (done via ioctl),
could you see if all the ioctl failed ? Then assuming it goes though
we go look up the version later in that function (at detect_v2)
and call virXen_getdomaininfo() to do so, could you trace through it
and virXen_getdomaininfolist() to see what actually happens ?
thanks a lot !
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
3:46 a.m.
Hi, Daniel
I will investigate this issue.
But Nextweek I am absent (for XenSummit).
In this case, ask Nobuhiro (Ito).
Thanks
Atsushi SAKAI
Daniel Veillard <veillard(a)redhat.com> wrote:
On Fri, Apr 13, 2007 at 02:37:03PM +0900, Atsushi SAKAI wrote:
> Hi, Dan
>
> I test on Fedora7 test3 x86_64 but failed.
> (Old version(which includes test3) works fine.)
> virsh dominfo 0
>
> libvir: error : no support for hypervisor (null)
> lt-virsh: error: failed to connect to the hypervisor
Hi Atsushi,
could you help us a bit with the debugging there, by running as root
lt-virsh under gdb and adding a breakpoint in xenHypervisorInit()
around line 1233 in xen_internal.c the version detection starts.
We test a couple of hypervisor call here (done via ioctl),
could you see if all the ioctl failed ? Then assuming it goes though
we go look up the version later in that function (at detect_v2)
and call virXen_getdomaininfo() to do so, could you trace through it
and virXen_getdomaininfolist() to see what actually happens ?
thanks a lot !
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
6:07 a.m.
On Fri, Apr 13, 2007 at 02:37:03PM +0900, Atsushi SAKAI wrote:
Hi, Dan
I test on Fedora7 test3 x86_64 but failed.
(Old version(which includes test3) works fine.)
virsh dominfo 0
libvir: error : no support for hypervisor (null)
lt-virsh: error: failed to connect to the hypervisor
Hmm, Fedora 7 test3 is still on Xen 3.0.4 so shouldn't have been impacted.
I'll double check on my own box too.
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 -=|
6:10 a.m.
Hi, Dan
This is my mistake. Fedora7 problem is not exist.
(I newly used machine and I do not know xen-devel is not in)
Anyway I found bug, for GetVersion.
(It is related to xen_unified.c)
I will send it later.
Thanks
Atsushi SAKAI
"Daniel P. Berrange" <berrange(a)redhat.com> wrote:
On Fri, Apr 13, 2007 at 02:37:03PM +0900, Atsushi SAKAI wrote:
> Hi, Dan
>
> I test on Fedora7 test3 x86_64 but failed.
> (Old version(which includes test3) works fine.)
> virsh dominfo 0
>
> libvir: error : no support for hypervisor (null)
> lt-virsh: error: failed to connect to the hypervisor
Hmm, Fedora 7 test3 is still on Xen 3.0.4 so shouldn't have been impacted.
I'll double check on my own box too.
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 -=|
7:11 a.m.
Hi, Dan
Just for 64bit issue.
Tomohiro(Takahashi) check virsh(libvirt)
on xen-ia64-unstable 14828
virsh works fine!
So We can test libvirt on current xen-unstable!
Thanks
Atsushi SAKAI
"Daniel P. Berrange" <berrange(a)redhat.com> wrote:
On Fri, Apr 13, 2007 at 02:37:03PM +0900, Atsushi SAKAI wrote:
> Hi, Dan
>
> I test on Fedora7 test3 x86_64 but failed.
> (Old version(which includes test3) works fine.)
> virsh dominfo 0
>
> libvir: error : no support for hypervisor (null)
> lt-virsh: error: failed to connect to the hypervisor
Hmm, Fedora 7 test3 is still on Xen 3.0.4 so shouldn't have been impacted.
I'll double check on my own box too.
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 -=|
6433
days inactive
6434
days old
13 comments
4 participants
participants (4)
-
Atsushi SAKAI -
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones