This is how the adresses are passed through the stack:
(read this monospaced)
userspace-libvirt
linux-kernel Xen
alloc/ioctl -> incoming -> xencomm_map ->
incoming -> xencomm_inline_to_guest
0xffba2eb0 -> ffba2eb000000000 -> bfba2eb000000000 ->
bfba2eb000000000 -> 0x3fba2eb000000000
The xencomm_map function is from our patchqueue for the xen-2.6.18
powerpc merge
It uses xencomm_create_inline which xencomm_pa and adds the
XENCOMM_INLINE_FLAG
flag With the correct 0x80000000 00000000 adresses this works but it
fails for
the wrong 0xff... address received in the bug scenario.
All lower effects are only subsequent effects
Since the numeric value of 0xffba2eb0 in userspace is different to the one
received by the kernel 0xffba2eb000000000 and its just the upper/lower half
that is twisted it may be some kind of little/big endian bug here
(0x00000000ffba2eb0 would be right).
In libvirt src/xen_internal.c the assignment of the buffer struct is a bit
confusing because it relies on global variables through the stack etc.
This is how I think it works (or better doesn't) and somewhere here I
get lost:
-> the identified userspace call causing the bug is xenHypervisorDoV2Sys
with hypervisor_version=2 && sys_interface_version=3
-> the identified call used the dominfos->v2d5 to assign it to buffer.v
-> difference of v2 and v2d5 : v2d5 uses ALIGN_64 for all 64 bit vars
which is
sysctl version 3 style
-> also the .v above is used to pack buffer in a 64bit aligned stuct for
sysctl
version 3
-> The dominfo struct use here is assigned in virXen_getdomaininfo and is
&(dominfo->v2); or &(dominfo->v0);
-> I already debugged this, the critical call comes from xenHypervisorInit
Here the local &info struct gets passed to virXen_getdomaininfo which is
later accessed with &(dominfo->v2);
=>The dominfos->v2d5 should be empty maybe thats why it fails ?
1. info of type xen_getdomaininfo is allocated locally in
xenHypervisorInit
2. then its passed to virXen_getdomaininfo
2. virXen_getdomaininfo allocates a new local local xen_getdomaininfolist
called dominfos
3. depending on hypervisor_version there the v0 or the v2 part of the
submitted info struct gets assigned (!no v2d5 assignment!)
4. now we should have a xen_getdomaininfolist thats filled with either
"dominfos.v0=&(dominfo->v0);" or "dominfos.v2=&(dominfo->v2);" but is
never assigned an therefore undefined
5. This dominfos struct is passed by reference to virXen_getdomaininfolist
6. depending on hypervisor_version and sys_interface_version the code now
accesses in our bug scenario the v2d5 field (which should be in the
best
case undefined)
7. This op struct with the assingnment from v2d5 as buffer.v now gets
passed
to Xen which later fails to handle that
Because the stack is not cleaned and the call to sysctl version 2/3 is very
close and similar it might be possible that we access accidentially the data
of the v2 call wth the v3 layout and becaue of that our buffer address
may be
shifted 32bits.
As a quick test I did the following in virXen_getdomaininfo
memset(&dominfos, 0, sizeof(dominfos));
-> zeroing local variable should never hurt except something like the
described
buggy stack usage is around and as expected I get segmentation faults if
I zero the
dominfos struct.
The initial approach to fix that is:
if (hypervisor_version < 2) {
dominfos.v0 = &(dominfo->v0);
} else {
if (sys_interface_version < 3)
dominfos.v2 = &(dominfo->v2);
else
dominfos.v2d5 = &(dominfo->v2d5);
}
But I realized that &(dominfo->v2) == &(dominfo->v0) == &(dominfo->v2d5)
which
should all three be subparts of a struct and therefore the adresses
should not
be the same.
union xen_getdomaininfolist {
struct xen_v0_getdomaininfo *v0;
struct xen_v2_getdomaininfo *v2;
struct xen_v2d5_getdomaininfo *v2d5;
};
typedef union xen_getdomaininfolist xen_getdomaininfolist;
Here is the debugging output related to this from gdb and my debugging
statements.
gdb --args /usr/bin/python mytest.py
I may overlook something but I think the addresses should be
different and the "print *op" in xenHypervisorDoV2Sys should not always see
getdomaininfolist and getdomaininfolists3 filled at the same time.
Breakpoint 2 at 0xf671534: file xen_internal.c, line 824.
Pending breakpoint "xenHypervisorDoV2Sys" resolved
Initialize Libvirtmod (sleepwait)
virXen_getdomaininfo - assigning &(dominfo->v2) '0xffb29eb0'
virXen_getdomaininfolist - enter for firstdomain '0' maxids '1' on
handle '9'
virXen_getdomaininfolist - sys_interface_version '2' hypervisor_version '2'
virXen_getdomaininfolist - dominfos->v2 '0xffb29eb0' dominfos->v2d5
'0xffb29eb0'
virXen_getdomaininfolist - sleepwait
[Switching to Thread 0xf7fc2000 (LWP 4876)]
Breakpoint 2, xenHypervisorDoV2Sys (handle=9, op=0xffb29d00) at
xen_internal.c:824
warning: Source file is more recent than executable.
824 memset(&hc, 0, sizeof(hc));
(gdb) print *op
$1 = {cmd = 6, interface_version = 0, u = {getdomaininfolist =
{first_domain = 0, max_domains = 1, buffer = 0xffb29eb0, num_domains = 1},
getdomaininfolists3 = {first_domain = 0, max_domains = 1, buffer =
{v = 0xffb29eb0, pad = 18424963504277553153}, num_domains = 0},
getschedulerid = {sched_id = 0}, padding = {0 '\0', 0 '\0', 0 '\0',
0 '\0', 0 '\0', 0 '\0', 0 '\0', 1 '\001', 255 '', 178 '',
158 '\236', 176 '', 0 '\0', 0 '\0', 0 '\0', 1 '\001', 0 '\0'
<repeats 112 times>}}}
(gdb) c
Continuing.
virXen_getdomaininfo - assigning &(dominfo->v2d5) '0xffb29eb0'
virXen_getdomaininfolist - enter for firstdomain '0' maxids '1' on
handle '9'
virXen_getdomaininfolist - sys_interface_version '3' hypervisor_version '2'
virXen_getdomaininfolist - dominfos->v2 '0xffb29eb0' dominfos->v2d5
'0xffb29eb0'
virXen_getdomaininfolist - sleepwait
Breakpoint 2, xenHypervisorDoV2Sys (handle=9, op=0xffb29d00) at
xen_internal.c:824
824 memset(&hc, 0, sizeof(hc));
(gdb) print *op
$2 = {cmd = 6, interface_version = 0, u = {getdomaininfolist =
{first_domain = 0, max_domains = 1, buffer = 0xffb29eb0, num_domains = 0},
getdomaininfolists3 = {first_domain = 0, max_domains = 1, buffer =
{v = 0xffb29eb0, pad = 18424963504277553152}, num_domains = 1},
getschedulerid = {sched_id = 0}, padding = {0 '\0', 0 '\0', 0 '\0',
0 '\0', 0 '\0', 0 '\0', 0 '\0', 1 '\001', 255 '', 178 '',
158 '\236', 176 '', 0 '\0', 0 '\0', 0 '\0', 0 '\0', 0 '\0', 0
'\0', 0 '\0', 1 '\001', 0 '\0' <repeats 108 times>}}}
(gdb) c
Continuing.
-> Bug
I attached the current debug/workaround/testfix diff (not nice but
working ;-) ) as well as my minimal debug python skript.
It's late today - Have fun to continue Jerone ;)
Jerone Young wrote:
On Tue, 2007-06-26 at 15:29 +0200, Christian Ehrhardt wrote:
Hi,
here is a very rude text that shows how far I get today. It's more or
less a text file where I copy&paste everything I find over the day.
It is a lot of stuff, but reading it brings us completely to the same
page in this issue. It should be some kind of readable if you read it
top->down.
BTW - I got no mail from you yesterday. This might have two reasons:
a) you did not send one - well thats no problem for me ;)
b) you send one and I didn't receive it - I had this issue once with
Hollis where mails needed up to 5 days. Since that we always used notes
& imap mail addresses for the mails to be sure (was an imap server issue)
First FYI:
In addition to your mail you need the following to be able to compile
libvirt, virt-manager and virtinst:
libssldevel
ncurses-devel
libtool
libxml2
gnutls
phyton-urlgrabber
pygtk2-devel
gtk2-devel
now you have a complete list ;)
Thanks I probably just didn't put these there. But yes all these need to
be added to the grand list :-)
Then if youhave your custom xen with 2.6.18 xenolinux somewhere you need
to make the headers available
ln -s
/root/xen_2.6.18/xen-unstable.hg/linux-2.6.18-xen.hg/include/xen/public/
/usr/include/xen/linux
ln -s /root/xen_2.6.18/xen-unstable.hg/xen/include/public /usr/include/xen
Replace /root/xen_2.6.18/xen-unstable.hg with your xen directory
Replace xen_2.6.18/xen-unstable.hg/linux-2.6.18-xen.hg with your
xenolinux directory
Well what you really need is just the xen headers. So they can be found
in the xen source. Just downloading the xen-unstable and doing "make
xen-install" (I think that's it). Will install all the needed headers
onto the system.
install virtinst
The compilation of virtinst causes the same Bug described than "virsh -r
-t -d 5 connect".
It occurs while trying to execute autobuild. Isolated the part "python
setup.py test" of the
autobuild process of virtinst.
(XEN) pfn2mfn: Dom[0] pfn 0x3fefdfc000000 is not a valid page
(XEN) paddr_to_maddr: Dom:0 bad paddr: 0x3fefdfc000000000
I have a feeling this has little to do with virtinst and more to do with
python exposing a problem in our Xen kernel.
In setup.py tracked down to the call that also appers with a tracestack:
The buggy thing is the "import tests.xmlconfig" that gets generated.
If I skip the xmlconfig part test.coverage gets loaded without issues
which implies that the load of test.xmlconfig should not be a
path/directory issue.
This is very interesting. I figure another python module whould set this
off also. Maybe test.xmlconfig is executing something that the others
are not.
-> A simple python script just containing the "import tests.xmlconfig"
casues the bug, use this to debug this issue
-> The code printing that "bad paddr" is in "arch/powerpc/usercopy.c"
=> where is the connection
Ok yeap, just as I figured. I'm willing to bet this starts in
arch/powerpc/platforms/xen/hcall.c
I'll see if I get some free time this eveing to create the 2.6.18 kernel
you guys have, to narrow it down even more.
pbclient4:~/libvirt/virtinst-0.103.0 # cat mytest.py
import pdb
pdb.set_trace();
import tests.xmlconfig
Tracked down with pdb debugger (every -> is the triggering function one
step deeper in the stack)
pbclient4:~/libvirt/virtinst-0.103.0 # gdb --args /usr/bin/python mytest.py
import xmlconfig
-> From Guest Guest
-> import libvirt
This is not virtinst, its libvirt python binding in
/usr/local/python2.5/site-packages/libvirt.py
-> import libvirtmod
=> this is the c mapper to map python to C functions (partially
generated code)
-> in that code the bug is in virInitialize() which is called once initially
+use GDB to debug virInitialize
Ths is no more python bindings of libvirt/python its src/libvirt.c:57
-> without bug through some virRegisterDriver (driver=0xf6b7488) at
libvirt.c:222 for test & qemu
-> fails at
74 #ifdef WITH_XEN
75 if (xenUnifiedRegister () == -1) return -1;
-> Breakpoint 2, xenUnifiedRegister () at xen_unified.c:923
-> bug at/below xenHypervisorInit()
-> Breakpoint 2, xenHypervisorInit () at xen_internal.c:1703
-> bug at/below 1839 if (virXen_getdomaininfo(fd, 0, &info) == 1) {
-> wrapper to virXen_getdomaininfolist()
=> the working one is later "Using hypervisor call v2, sys ver3 dom ver5" so
the buggy one should just fail and go on without bad paddr
-> hyp v 2 sys v 2 working but not the "wanted" one
-> hyp v 2 sys v 3
-> last libvirt function in buggy call stack is "xenHypervisorDoV2Sys"
it issues an ioctl hypercall that then fails at the known bad paddr
Last critical point in Dom0 userspace is the ioctl call with the parameters:
(gdb) print hc.op
$14 = 35
(gdb) print *op
$15 = { cmd = 6,
interface_version = 0,
u = {getdomaininfolist = { first_domain = 0,
max_domains = 1,
buffer = 0xff875eb0,
num_domains = 0},
getdomaininfolists3 = { first_domain = 0,
max_domains = 1,
buffer = {v = 0xff875eb0, pad = 18412789711534817280},
num_domains = 1},
getschedulerid = {sched_id = 0},
padding = {0 '\0', 0 '\0', 0 '\0', 0 '\0', 0 '\0', 0 '\0', 0 '\0', 1
'\001', 255 '', 135 '\207', 94 '^', 176 '', 0 '\0', 0 '\0', 0 '\0', 0
'\0', 0 '\0', 0 '\0', 0 '\0', 1 '\001', 0 '\0' <repeats 108 times>}}}
(gdb) print sys_interface_version
$16 = 3
This ends in the bad paddr report - see how the address is became
modified to 0x3f... removing the first 0xf I assume this is where things
go wrong.
The ioctl is executed and we see the buffer address as the one reported
as bad:
(XEN) pfn2mfn: Dom[0] pfn 0x3f875eb000000 is not a valid page
(XEN) paddr_to_maddr: Dom:0 bad paddr: 0x3f875eb000000000
Background of the used hypercall:
Hypercall 35 with command 6 is : do_sysctl which is in common/sysctl.c and
maps to arch/powerpc/sysctl.c if needed
command 6 is handled by common code
DEFINITION:
#define XEN_SYSCTL_getdomaininfolist 6
struct xen_sysctl_getdomaininfolist {
/* IN variables. */
domid_t first_domain;
uint32_t max_domains;
XEN_GUEST_HANDLE_64(xen_domctl_getdomaininfo_t) buffer;
/* OUT variables. */
uint32_t num_domains;
};
IMPLEMENTATION (common code):
case XEN_SYSCTL_getdomaininfolist:
{
struct domain *d;
struct xen_domctl_getdomaininfo info;
u32 num_domains = 0;
rcu_read_lock(&domlist_read_lock);
for_each_domain ( d )
{
if ( d->domain_id < op->u.getdomaininfolist.first_domain )
continue;
if ( num_domains == op->u.getdomaininfolist.max_domains )
break;
getdomaininfo(d, &info);
if ( copy_to_guest_offset(op->u.getdomaininfolist.buffer,
num_domains, &info, 1) )
{
ret = -EFAULT;
break;
}
num_domains++;
}
rcu_read_unlock(&domlist_read_lock);
if ( ret != 0 )
break;
op->u.getdomaininfolist.num_domains = num_domains;
if ( copy_to_guest(u_sysctl, op, 1) )
ret = -EFAULT;
}
break;
-> debug this with print statements checking addresses
A valid section from some other call looks like this:
[...]
(XEN) xencomm_copy_to_guest - from '000000000cff38a5' to
'0000000017eb7000' about '2' bytes skipping '0'
(XEN) xencomm_copy_to_guest - desc '00000001e1eb7000'
(XEN) cff38a5[2] -> 1e6e456d8
(XEN) xencomm_copy_to_guest - from '000000000cff38a4' to
'0000000017eb7000' about '1' bytes skipping '2'
(XEN) xencomm_copy_to_guest - desc '00000001e1eb7000'
(XEN) cff38a4[1] -> 1e6e456da
(XEN) xencomm_copy_to_guest - from '000000000cff38a4' to
'0000000017eb7000' about '1' bytes skipping '3'
(XEN) xencomm_copy_to_guest - desc '00000001e1eb7000'
(XEN) cff38a4[1] -> 1e6e456db
(XEN) 1ec68f920[144] -> cff3ad0
(XEN) cff3ad0[144] -> 1ec68f920
(XEN) 1ec68f920[144] -> cff3ad0
[...]
The buggy call to do_sysctl contians already the:
[...]
(XEN) do_sysctl: cmd '6' parameters op->u.getdomaininfolist.first_domain
'0' op->u.getdomaininfolist.max_domains '1'
op->u.getdomaininfolist.buffer.p 'bfb40a1000000000' adress of info
'0000000000227b78'
(XEN) do_sysctl: iterate domain '0' num_domains '0'
(XEN) do_sysctl: post getdomaininfo, pre copy_to_guest_offset
(XEN) pfn2mfn: Dom[0] pfn 0x3fb40a1000000 is not a valid page
(XEN) paddr_to_maddr: Dom:0 bad paddr: 0x3fb40a1000000000
(XEN) 227b78[72] -> 0
(XEN) do_sysctl: pre copy_to_guest u_sysctl.p '800000000cffb810' op
'0000000000227ae0'
(XEN) 227ae0[136] -> 1ecffb810
(XEN) 1ecffb1e0[4] -> 227b6c
(XEN) 1ecffb1e0[4] -> 227b6c
(XEN) 1e2393400[4] -> 23fba0
[...]
So from above we saw the mappign from python to Xen:
buffer = {v = 0xff875eb0, pad = 18412789711534817280},
(XEN) pfn2mfn: Dom[0] pfn 0x3f875eb000000 is not a valid page
While I assume it should be something like 0x800000000f875eb or
0x0000000ff875eb but not 0x3f...
My current plan is:
1. remove some of the slowing down debug statements I already have
2. add more statements to check valid calls and which addresses they are
using
2b. Hoping you will send me an easy "should be 0x0000000semething
because whatever" mail ;9
Will try to get to you before you come in tommorow.
3. checkn the flow through the kernel from the sysctl call to the
hypercall if there is e.g. a ifdef aroud a __pa or something like that
I'm not sure, but I'll try to come online this evening so we can chat
about it.
It's ok .. I've been somewhat distracted (by other issues) but they are
now over. If things test well with my multiboot patch today I'll be on
this fulltime with you. I'll look more into the issues your are having
and get you an email before you come in tommorow.
Great work!
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
+49 7031/16-3385
Ehrhardt@xxxxxxxxxxxxxxxxxx
Ehrhardt@xxxxxxxxxx
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Johann Weihen
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
diff -r 57c3b9568ea6 python/libvir.c
--- a/python/libvir.c Thu Jul 19 13:52:36 2007 +0200
+++ b/python/libvir.c Fri Jul 20 16:33:12 2007 +0200
@@ -15,6 +15,8 @@
#include "libvirt_wrap.h"
#include "libvirt-py.h"
+#define DEBUG_ERROR
+
extern void initlibvirtmod(void);
PyObject *libvirt_virDomainGetUUID(PyObject *self ATTRIBUTE_UNUSED, PyObject
*args);
@@ -95,7 +97,7 @@ libvirt_virErrorFuncHandler(ATTRIBUTE_UN
PyObject *result;
#ifdef DEBUG_ERROR
- printf("libvirt_virErrorFuncHandler(%p, %s, ...) called\n", ctx, msg);
+ printf("libvirt_virErrorFuncHandler(%p) called\n", ctx);
#endif
if ((err == NULL) || (err->code == VIR_ERR_OK))
@@ -688,10 +690,22 @@ initlibvirtmod(void)
if (initialized != 0)
return;
+ // DEBUG
+ printf("Initialize Libvirtmod (sleepwait)\n");
+ sleep(5);
+
virInitialize();
+
+ // DEBUG
+ printf("post Initialize Libvirtmod / pre py_InitModule (sleepwait)\n");
+ sleep(5);
/* intialize the python extension module */
Py_InitModule((char *) "libvirtmod", libvirtMethods);
+
+ // DEBUG
+ printf("post py_InitModule (sleepwait)\n");
+ sleep(5);
initialized = 1;
}
diff -r 57c3b9568ea6 python/libvir.py
--- a/python/libvir.py Thu Jul 19 13:52:36 2007 +0200
+++ b/python/libvir.py Fri Jul 20 16:31:17 2007 +0200
@@ -4,6 +4,9 @@
# Check python/generator.py in the source distribution of libvir
# to find out more about the generation process
#
+import pdb
+pdb.set_trace()
+
import libvirtmod
import types
diff -r 57c3b9568ea6 src/libvirt.c
--- a/src/libvirt.c Thu Jul 19 13:52:36 2007 +0200
+++ b/src/libvirt.c Fri Jul 20 17:07:51 2007 +0200
@@ -72,7 +72,7 @@ virInitialize(void)
if (qemuRegister() == -1) return -1;
#endif
#ifdef WITH_XEN
- if (xenUnifiedRegister () == -1) return -1;
+ if (xenUnifiedRegister() == -1) return -1;
#endif
#ifdef WITH_REMOTE
if (remoteRegister () == -1) return -1;
diff -r 57c3b9568ea6 src/xen_internal.c
--- a/src/xen_internal.c Thu Jul 19 13:52:36 2007 +0200
+++ b/src/xen_internal.c Sun Jul 22 05:45:45 2007 +0200
@@ -36,6 +36,8 @@
#include <xen/sched.h>
#include "xml.h"
+
+#define DEBUG
/* #define DEBUG */
/*
@@ -904,24 +906,36 @@ virXen_getdomaininfolist(int handle, int
{
int ret = -1;
+
if (mlock(XEN_GETDOMAININFOLIST_DATA(dominfos),
XEN_GETDOMAININFO_SIZE * maxids) < 0) {
virXenError(VIR_ERR_XEN_CALL, " locking",
XEN_GETDOMAININFO_SIZE * maxids);
return (-1);
}
+
+ printf("%s - enter for firstdomain '%d' maxids '%d' on handle
'%d'\n",__func__,first_domain,maxids,handle);
+ printf("%s - sys_interface_version '%d' hypervisor_version
'%d'\n",__func__,sys_interface_version,hypervisor_version);
+ printf("%s - dominfos->v2 '%p' dominfos->v2d5
'%p'\n",__func__,dominfos->v2,dominfos->v2d5);
+ printf("%s - sleepwait\n",__func__);
+ sleep(5);
+
if (hypervisor_version > 1) {
xen_op_v2_sys op;
memset(&op, 0, sizeof(op));
op.cmd = XEN_V2_OP_GETDOMAININFOLIST;
+
+ printf("%s - allocated new and clean xen_op_v2_sys\n",__func__);
if (sys_interface_version < 3) {
+ printf("%s - assiigning getdomaininfolist stuff \n",__func__);
op.u.getdomaininfolist.first_domain = (domid_t) first_domain;
op.u.getdomaininfolist.max_domains = maxids;
op.u.getdomaininfolist.buffer = dominfos->v2;
op.u.getdomaininfolist.num_domains = maxids;
} else {
+ printf("%s - assiigning getdomaininfolist3 stuff \n",__func__);
op.u.getdomaininfolists3.first_domain = (domid_t) first_domain;
op.u.getdomaininfolists3.max_domains = maxids;
op.u.getdomaininfolists3.buffer.v = dominfos->v2d5;
@@ -973,11 +987,20 @@ virXen_getdomaininfo(int handle, int fir
virXen_getdomaininfo(int handle, int first_domain,
xen_getdomaininfo *dominfo) {
xen_getdomaininfolist dominfos;
+ memset(&dominfos, 0, sizeof(dominfos));
if (hypervisor_version < 2) {
dominfos.v0 = &(dominfo->v0);
+ printf("%s - assigning &(dominfo->v0) '%p'\n",__func__,&(dominfo->v0));
} else {
- dominfos.v2 = &(dominfo->v2);
+ if (sys_interface_version < 3) {
+ dominfos.v2 = &(dominfo->v2);
+ printf("%s - assigning &(dominfo->v2)
'%p'\n",__func__,&(dominfo->v2));
+ }
+ else {
+ dominfos.v2d5 = &(dominfo->v2d5);
+ printf("%s - assigning &(dominfo->v2d5)
'%p'\n",__func__,&(dominfo->v2d5));
+ }
}
return virXen_getdomaininfolist(handle, first_domain, 1, &dominfos);
@@ -1762,7 +1785,7 @@ xenHypervisorInit(void)
if ((ret != -1) && (ret != 0)) {
#ifdef DEBUG
- fprintf(stderr, "Using new hypervisor call: %X\n", ret);
+ printf(stderr, "Using new hypervisor call: %X\n", ret);
#endif
hv_version = ret;
xen_ioctl_hypercall_cmd = cmd;
@@ -1779,7 +1802,7 @@ xenHypervisorInit(void)
ret = ioctl(fd, cmd, (unsigned long) &v0_hc);
if ((ret != -1) && (ret != 0)) {
#ifdef DEBUG
- fprintf(stderr, "Using old hypervisor call: %X\n", ret);
+ printf(stderr, "Using old hypervisor call: %X\n", ret);
#endif
hv_version = ret;
xen_ioctl_hypercall_cmd = cmd;
@@ -1808,7 +1831,7 @@ xenHypervisorInit(void)
ipt = malloc(sizeof(virVcpuInfo));
if (ipt == NULL){
#ifdef DEBUG
- fprintf(stderr, "Memory allocation failed at xenHypervisorInit()\n");
+ printf(stderr, "Memory allocation failed at xenHypervisorInit()\n");
#endif
return(-1);
}
mytest.py
Description: application/python
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|
Home