xenaccess-devel Mailing List for XenAccess Library (Page 4)
Status: Beta
Brought to you by:
bdpayne
Menu
▾
▴
xenaccess-devel — General list for all technical issues related to the XenAccess Library
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(6) |
Jul
(21) |
Aug
(13) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(9) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(13) |
Sep
|
Oct
|
Nov
(4) |
Dec
(8) |
| 2008 |
Jan
(14) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bryan D. P. <br...@th...> - 2006-07-29 18:06:44
|
FYI, version 0.2 is now available for download. The major changes from 0.1 to 0.2 include: * Caching -- addresses are cached to avoid duplicate page table lookups and/or disk access (e.g., looking in System.map to find a vaddr for a kernel symbol). You should see a visible difference in the speed of basic operations (e.g., run module-list in 0.1 followed by module-list in 0.2). Cache size is configurable by changing the value of XA_CACHE_SIZE in xa_private.h, but the default value should be good for most people. The cache operates by removing the least recently used item when it needs to add a new entry (i.e., it is an LRU cache). * Compatibility with Xen 3.0.2 -- many people have reported trouble using v0.1 with the 2.6.16 kernel in more recent versions of Xen. This release aims to address these problems. As always, let me know if you have any questions. Enjoy, bryan - Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org |
|
From: Daniele S. <da...@ya...> - 2006-07-29 10:47:20
|
> I've only tested this with the kernels built directly > from xen. I'm not sure > if fedora uses a different kernel configuration. I've also tried building from sources (the 3.0.2 version), but it had the same problem > If you'd prefer to not test / play with that > version, just let me know and > I'll go ahead and push out the 0.2 release this > evening. Ok, go ahead with the new relase, I'll play with it very soon :-) Thanks! Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
|
From: Daniele S. <da...@ya...> - 2006-07-28 14:58:32
|
--- "Bryan D. Payne" <br...@th...> ha scritto: > I'm playing with XenAccess this evening and I don't > seem to have the > problem that you do. Are you using the release > version (0.1) or the > version from subversion? I'm getting ready to > release the next > version, but I'd like to make sure that this issue > is resolved first :-) > I'm using the 0.1 version (the one downloadable from the main page). I have a Fedora 5 distribution with an unmodified version of Xen (I mean, not recompiled): # uname -r 2.6.16-1.2133_FC5xen0 > > PS... Here's a kernel module that you can run in > domU to get the same > information (start_code, etc). You can use this to > see if the > XenAccess output is correct. On my machine, they > match. > > http://linuxgazette.net/112/misc/krishnakumar/print_kern_ds.c.txt This is the output of process-data from dom0: #./run ./process-data | head -12 Memory descriptor addresses for pid = 1: start_code = 0xc03e2e88 end_code = 0xc03e2e88 start_data = 0x00000035 end_data = 0x00000009 start_brk = 0x0000003b brk = 0x000000ad start_stack = 0x000000ac arg_stack = 0x00000000 arg_end = 0x00000073 env_start = 0x00000071 env_end = 0x00000016 This is the output of pmap from domU (a Slackware distribution): # pmap 1 1: init [5] 00194000 8K r-x-- /lib/libdl-2.4.so 00196000 4K r-x-- /lib/libdl-2.4.so 00197000 4K rwx-- /lib/libdl-2.4.so 0073b000 4K r-x-- [ anon ] 0073c000 100K r-x-- /lib/ld-2.4.so 00755000 4K r-x-- /lib/ld-2.4.so 00756000 4K rwx-- /lib/ld-2.4.so 0081e000 1212K r-x-- /lib/i686/nosegneg/libc-2.4.so 0094d000 12K r-x-- /lib/i686/nosegneg/libc-2.4.so 00950000 4K rwx-- /lib/i686/nosegneg/libc-2.4.so 00951000 12K rwx-- [ anon ] 00cf6000 12K r-x-- /lib/libsetrans.so.0 00cf9000 4K rwx-- /lib/libsetrans.so.0 00de2000 80K r-x-- /lib/libselinux.so.1 00df6000 8K rwx-- /lib/libselinux.so.1 00fa9000 224K r-x-- /lib/libsepol.so.1 00fe1000 4K rwx-- /lib/libsepol.so.1 00fe2000 40K rwx-- [ anon ] 08048000 32K r-x-- /sbin/init 08050000 4K rw--- /sbin/init 0908f000 132K rw--- [ anon ] b7f16000 8K rw--- [ anon ] b7f33000 4K rw--- [ anon ] bfc1e000 84K rw--- [ stack ] fbffd000 4K ----- [ anon ] Moreover, it seems that for every pid, I have (more or less) the same result. I've tried to do something like this: for(vaddr = 0; ; vaddr+=XC_PAGE_SIZE) { memory = xa_access_user_virtual_address( &xai, vaddr, &offset, pid); if(memory != NULL) { printf("not a valid address [0x%lx]\n", vaddr); } else { printf("valid address [0x%lx]\n", vaddr); } } and the valid addresses are in the range above 0xc0000000. I hope these information can help you. Cheers Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
|
From: Bryan D. P. <br...@th...> - 2006-07-25 16:32:09
|
I'm not sure that I would trust those values :-) Your intuition is right that these addresses would be in the kernel space and that the start and end code addresses should be different. I had some problems with this functionality when Xen upgraded to the 2.6.16 kernel. Specifically, the offsets where this data is located changed and I haven't had the time to figure out the new offsets yet. Ultimately, I'm interested in a longer term solution that would determine the offsets automatically. In the near term, if you want to get the correct values then you could dump the memory from this process's task struct and determine the offset to the appropriate values. I'll try to set asside some time this week to do this and get the correct offsets into subversion. Cheers, bryan On Tue, 25 Jul 2006, Daniele Sgandurra wrote: > Hello! > There are a couple of questions I would like to ask > you: this is the the output from process-data: > > start_code = 0xc03e2e88 > end_code = 0xc03e2e88 > [...] > > Why "start_code" and "end_code" are the same address? > (I've tried with other pids and the result is the > same). > My other question is about the fact that in Linux code > above 0xc0000000 is kernel code, so are these > addresses remapped? (I see that there are two types of > memory in Xen: a 'machine memory' and a > 'pseudo-physical memory', but I'm not sure it has > something to do with it..) > > Thanks! > > > > Chiacchiera con i tuoi amici in tempo reale! > http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > XenAccess-devel mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenaccess-devel > |
|
From: Daniele S. <da...@ya...> - 2006-07-25 15:42:17
|
Hello! There are a couple of questions I would like to ask you: this is the the output from process-data: start_code = 0xc03e2e88 end_code = 0xc03e2e88 [...] Why "start_code" and "end_code" are the same address? (I've tried with other pids and the result is the same). My other question is about the fact that in Linux code above 0xc0000000 is kernel code, so are these addresses remapped? (I see that there are two types of memory in Xen: a 'machine memory' and a 'pseudo-physical memory', but I'm not sure it has something to do with it..) Thanks! Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
|
From: Daniele S. <da...@ya...> - 2006-07-20 19:33:27
|
> Ideally, I'd like for XenAccess to provide some > capability for doing this. > I'm thinking of a function that takes a start and > end vaddr and returns > the memory. Or perhaps a start vaddr and a length. > Something along these > lines. Until that's added to the API, you'll want > to continue down the > path that you're discussing. Or, if you'd like to > add it to the API, I'd > be happy to accept the patch :-) > > Cheers, > bryan > Thanks for your complete answer! In the next few days I'll go on with some experiments about it, and if I get to something working and useful I will post here, if that's ok :-) Thanks again. Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
|
From: Bryan D. P. <br...@th...> - 2006-07-20 17:16:16
|
> Is it possible to print a whole section of a process
> from a domain (for example the code section)?
Yes... see more details below.
> -----------------------------------------
> unsigned long vaddr;
> .....
>
> for(vaddr = taskaddr.start_code; vaddr <=
> taskaddr.start_end; vaddr++)
> {
> memory = xa_access_user_virtual_address(&xai,
> vaddr, &offset, pid);
> if (NULL == memory){
> perror("failed to map memory");
> goto error_exit;
> }
> print_hex(memory, XA_PAGE_SIZE);
> }
> ....
> -----------------------------------------
This is close. The problem here is that you are incrementing vaddr one
byte at a time, but printing out an entire page of memory at a time. So
you'll get the same page many times in a row.
The xa_access_user_virtual_address function will return a pointer to the
*start* of the page in memory that contains the vaddr in question. The
value of <offset> will be the offset into that page where you will find
vaddr.
> I'm not sure if the addresses found in
> "xa_linux_taskaddr_t" are page-frame identifiers or
> virtual addresses.
They are virtual addresses. These values are identical to what you would
find in the kernel's mm_struct structure. In fact, I populate those
values by copying directly from the mm_struct structure.
> I've looked through the code, and I see that the
> virtual address (vaddr) is first mapped to the
> physical address and then to the physical frame and
> then "xc_map_foreign_range" is called with the
> parameter size=XC_PAGE_SIZE, and it returns a void *
> (through mmap) that points to a frame. Is that true?
Yes.
> Or should the previous code be something like:
> vaddr = taskaddr.start_code; vaddr <=
> taskaddr.start_end; vaddr+=XC_PAGE_SIZE)
This is closer to what you want, but not quite right. Imagine the case
where the code spans multiple pages of memory. The code above will
iterate through each page that holds the code, except for the last page
(unless the code completely filled that page). To fix this, you need your
loop termination condition to account for the fact that you'd want to
print any page that has at least one byte of the relavent code on it.
Ideally, I'd like for XenAccess to provide some capability for doing this.
I'm thinking of a function that takes a start and end vaddr and returns
the memory. Or perhaps a start vaddr and a length. Something along these
lines. Until that's added to the API, you'll want to continue down the
path that you're discussing. Or, if you'd like to add it to the API, I'd
be happy to accept the patch :-)
Cheers,
bryan
|
|
From: Daniele S. <da...@ya...> - 2006-07-20 16:12:27
|
Is it possible to print a whole section of a process
from a domain (for example the code section)?
For example (modifying process-data.c):
-----------------------------------------
unsigned long vaddr;
.....
for(vaddr = taskaddr.start_code; vaddr <=
taskaddr.start_end; vaddr++)
{
memory = xa_access_user_virtual_address(&xai,
vaddr, &offset, pid);
if (NULL == memory){
perror("failed to map memory");
goto error_exit;
}
print_hex(memory, XA_PAGE_SIZE);
}
....
-----------------------------------------
I'm not sure if the addresses found in
"xa_linux_taskaddr_t" are page-frame identifiers or
virtual addresses.
I've looked through the code, and I see that the
virtual address (vaddr) is first mapped to the
physical address and then to the physical frame and
then "xc_map_foreign_range" is called with the
parameter size=XC_PAGE_SIZE, and it returns a void *
(through mmap) that points to a frame. Is that true?
Or should the previous code be something like:
vaddr = taskaddr.start_code; vaddr <=
taskaddr.start_end; vaddr+=XC_PAGE_SIZE)
I hope I've made myself clear :)
Thanks!
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
|
|
From: Daniele S. <da...@ya...> - 2006-07-19 07:01:02
|
>Just add the following line to the xend > config and restart xend. > > (xend-unix-server yes) > > This seems to have fixed the problem at my end. > Please let me know if you > have any further trouble. > > -bryan > Thanks, now it works! Daniele Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
|
From: Bryan D. P. <br...@th...> - 2006-07-18 17:38:03
|
> Ok, I just confirmed that this is the problem. The temporary fix is to > use libvirt 0.1.1. In the mean time, I'll see what changed between these > versions in order to understand if the problem is with XenAccess of > libvirt. I ended up posting a question about this on the libvirt mailing list. It looks like the problem can be resolved by enabeling unix domain sockets in xend. Just add the following line to the xend config and restart xend. (xend-unix-server yes) This seems to have fixed the problem at my end. Please let me know if you have any further trouble. -bryan |
|
From: Daniele S. <da...@ya...> - 2006-07-18 15:54:17
|
> * What version of libvirt are you using? Is it > installed via rpm / yum or > straight from sources? If from source, are you > using any patches or > vanilla sources? Straight from the sources: it's the latest release 0.1.3 with no patches (that it's downloadable only from ftp) > * In your original email you show a nice output of > the function call > graph. Did you use a tool to get that or did you > manually add printf to > each function for printing out the info? I did it manually, just to figure out where the problem could be :) Thanks for everything Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
|
From: Bryan D. P. <br...@th...> - 2006-07-18 15:27:30
|
> Sorry, I just noticed in your original email that you are running 0.1.3. > I have 0.1.1 (from rpm) on my machine. Perhaps this is the root of the > problem? I'll run a quick test to see, and I'll let you know the results. Ok, I just confirmed that this is the problem. The temporary fix is to use libvirt 0.1.1. In the mean time, I'll see what changed between these versions in order to understand if the problem is with XenAccess of libvirt. Cheers, bryan |
|
From: Bryan D. P. <br...@th...> - 2006-07-18 15:16:20
|
> * What version of libvirt are you using? Is it installed via rpm / yum or > straight from sources? If from source, are you using any patches or > vanilla sources? Sorry, I just noticed in your original email that you are running 0.1.3. I have 0.1.1 (from rpm) on my machine. Perhaps this is the root of the problem? I'll run a quick test to see, and I'll let you know the results. -bryan |
|
From: Bryan D. P. <br...@th...> - 2006-07-18 14:54:28
|
> (and not freeing the return value of the first call to > this function), everything works fine, so it seems the > second time virDomainLookupByID is called it doesn't > work. Sorry for all the questions, but I have a couple more :-) * What version of libvirt are you using? Is it installed via rpm / yum or straight from sources? If from source, are you using any patches or vanilla sources? * In your original email you show a nice output of the function call graph. Did you use a tool to get that or did you manually add printf to each function for printing out the info? I'm not quite sure what is causing this problem yet, but we'll figure it out. Normally I would suggest upgrading to the latest svn revision, but the code that you're having trouble with has not changed in quite some time. Nevertheless, if you have the time to try the latest version from svn, I would be interested in knowing if it behaves differently. My guess is that it will be the same. Thanks, bryan |
|
From: Daniele S. <da...@ya...> - 2006-07-18 14:24:27
|
> Great, welcome to the list :-)
It's my pleasure :D
> Could you provide a little more information?
>
> * The code that is causing this problem
> * The version of XenAccess that you are using
> (stable or svn)
> * The version of Xen that you are using
> * The linux distro / version that you are using
> (e.g., FC5)
-The code I'm testing is examples/process_list.c, the
only thing I've added is:
if(argc > 1)
dom = atoi(argv[1]);
(so that I can check any domain)
-XenAccess version is 0.1
-My Xen version is 3.0.2-2 compiled from sources (with
AC module)
-My Linux distro is FC5 and this is the output of
uname -a:
Linux localhost.localdomain 2.6.16-xen #1 SMP Mon Jul
3 18:18:42 CEST 2006 i686 i686 i386 GNU/Linux
Anyway, if I add this little modification (just for
testing) to the file linux_domain_info.c
char *linux_get_kernel_name (int id)
{
.....
if(kernel != NULL) return kernel;
(and not freeing the return value of the first call to
this function), everything works fine, so it seems the
second time virDomainLookupByID is called it doesn't
work.
Thanks for your help!
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
|
|
From: Bryan D. P. <br...@th...> - 2006-07-18 12:48:56
|
> I've recently downloaded the XenAccess library which I think is > very nice and useful: I'd like to build something like an IDS for > XEN using XenAccess with Libvirt ...it's only an idea for now :) Great, welcome to the list :-) > I see that linux_predict_sysmap_name is called twice: when it's > invoked the second time, there is a problem with > virDomainLookupByID: probably it could be a libVirt error (for > example a pointer not updated, I'm using the latest version which > is now 0.1.3). > Is it possible to save the information obtained the first time by > linux_get_xml_info so that the second time it's not necessary to > call it again? Probably I still don't have a clear view of all the > code :) Caching is actually in the svn version of the code right now. But, I'm not sure that this is your problem here. It seems odd that you would be able to access domain 2 at one moment, and not a few moments later. Could you provide a little more information? * The code that is causing this problem * The version of XenAccess that you are using (stable or svn) * The version of Xen that you are using * The linux distro / version that you are using (e.g., FC5) Thanks, bryan - Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org |
|
From: Bryan D. P. <br...@th...> - 2006-07-18 12:35:48
|
> what is the required version of Xen to work with XenAccess? Do you > have any > policy about that? > I have tried the latest version from svn against xen3.0.2 and > module-list > example works, other examples don't. My goal has been to keep it working with the latest stable version. On my machine (running 3.0.2-2 at the moment), both module-list and process-list work. The process-data example has a minor issue with more recent kernels so it's output is gibberish (but it doesn't crash). Could you send the output of the broken commands so that I could figure out what's happening on your machine? Thanks, bryan - Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org |
|
From: Tomas K. <to...@ji...> - 2006-07-18 11:49:41
|
Hi, what is the required version of Xen to work with XenAccess? Do you have any policy about that? I have tried the latest version from svn against xen3.0.2 and module-list example works, other examples don't. Thanks for info. -- Tomas Kouba |
|
From: Daniele S. <da...@ya...> - 2006-07-18 09:12:22
|
Hi,
I've recently downloaded the XenAccess library which I think is very nice and useful: I'd like to build something like an IDS for XEN using XenAccess with Libvirt ...it's only an idea for now :)
I've tried to use the process_list program (modified so that it can work with any domain ID), but there are some little problems; I've put some printf at the begin and at the end of each function called and this is the resulting tree (the command is ./run ./process-list 2):
xa_init begin
xa_init end
helper_init
1) linux_predict_sysmap_name begin
linux_get_xml_info begin
virConnectOpenReadOnly
virDomainLookupByID
virDomainFree = [0]
virConnectClose = [0]
linux_get_xml_info end
linux_predict_sysmap_name kernel=[/boot/vmlinuz-2.6.16-xen]
linux_predict_sysmap_name end sysmap=[/boot/System.map-2.6.16-xen]
linux_system_map_symbol_to_address begin
linux_system_map_symbol_to_address end
helper_init end
xa_access_kernel_symbol begin
linux_access_kernel_symbol begin
2) linux_predict_sysmap_name begin
linux_get_xml_info begin
virConnectOpenReadOnly
virDomainLookupByID
(0) (null)
ERROR: Failed to find Domain 2
virConnectClose = [0]
linux_get_xml_info end
ERROR: failed to get domain info for domain id 2
ERROR: could not get kernel name for domain id 2
linux_predict_sysmap_name end sysmap=[(null)]
linux_system_map_symbol_to_address begin
fopen system map [(null)] error
linux_system_map_symbol_to_address end
xa_access_kernel_symbol end failure
failed to get process list head: Bad address
I see that linux_predict_sysmap_name is called twice: when it's invoked the second time, there is a problem with virDomainLookupByID: probably it could be a libVirt error (for example a pointer not updated, I'm using the latest version which is now 0.1.3).
Is it possible to save the information obtained the first time by linux_get_xml_info so that the second time it's not necessary to call it again? Probably I still don't have a clear view of all the code :)
Thanks!
Daniele
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
|
From: Bryan D. P. <br...@th...> - 2006-07-13 13:26:12
|
> I like the idea of XenAccess and will take a look at the source > code, but > there are some things not clear to me. Can somebody give me an > exmplanation? > > 1) What does XenAccess add to the libvirt functionality? As I saw > homepages > of both they seemed quite similar. XenAccess uses libvirt to obtain some basic information about the domain (e.g., version of the running kernel). However, there are many differences between the two libraries. Libvirt provides access to specific high-level information about the domains. Typically, this is the type of information that you can extract from the existing xen APIs. The benefit of libvirt is that it will be capable of getting this same information from other virtualization systems as well. On the other hand, XenAccess provides access to information about the OSes running inside each domain, and this information is not directly available through libvirt or any of the Xen libraries. For example, right now XenAccess provides raw kernel memory access whereas libvirt provides a string that indicates the kernel version. Both are useful, they just have different uses... > 2) The libvirt says: 'some very specific capabilities which are not > generic > enough may not be provided as libvirt APIs'. Do you plan to use > some direct > access to Xen via its API? (although it is pretty unstable now). XenAccess does, in fact, make use of libxc. This is the primary means for accessing memory in the other domains. Libxc seems to be stable from my experience. > 3) I use xen3.0.2 and the libvirt does not find dom 1 even there is > one > according to xm list: > > root@elf:/home/koubat/source/xen/xenaccess/trunk/libxa/examples > $ LD_PRELOAD=../libxenaccess.so ./module-list > (0) (null) > ERROR: Failed to find Domain 1 > ERROR: failed to get domain info for domain id 1 > ERROR: could not get kernel name for domain id 1 > ERROR: failed to lookup 'swapper_pg_dir' address > failed to init XenAccess library: Bad address > > root@elf:/home/koubat/source/xen/xenaccess/trunk/libxa/examples > $ xm list > Name ID Mem(MiB) VCPUs State Time(s) > Domain-0 0 744 2 r----- 16098.9 > ce 1 256 1 -b---- 342.5 Ahhh, yes. I believe that you're running into the same problem that someone else mentioned on this list a while back. The next release (coming soon!) will have an updated README file that addresses this problem. For now, I'll cut and paste the solution below. ---------- This looks like libvirt cannot connect to the Xend deamon. I believe that libvirt requires the xend-http-server to be enabled (which is no longer the default setting for Xen). Try adding or uncommenting the following line from /etc/xen/xend-config.sxp: (xend-http-server yes) After the edit you will need to restart xend: service xend restart ---------- I hope that helps... Cheers, bryan - Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org |
|
From: Tomas K. <to...@ji...> - 2006-07-13 11:19:46
|
Hi, I like the idea of XenAccess and will take a look at the source code, but there are some things not clear to me. Can somebody give me an exmplanation? 1) What does XenAccess add to the libvirt functionality? As I saw homepages of both they seemed quite similar. 2) The libvirt says: 'some very specific capabilities which are not generic enough may not be provided as libvirt APIs'. Do you plan to use some direct access to Xen via its API? (although it is pretty unstable now). 3) I use xen3.0.2 and the libvirt does not find dom 1 even there is one according to xm list: root@elf:/home/koubat/source/xen/xenaccess/trunk/libxa/examples $ LD_PRELOAD=../libxenaccess.so ./module-list (0) (null) ERROR: Failed to find Domain 1 ERROR: failed to get domain info for domain id 1 ERROR: could not get kernel name for domain id 1 ERROR: failed to lookup 'swapper_pg_dir' address failed to init XenAccess library: Bad address root@elf:/home/koubat/source/xen/xenaccess/trunk/libxa/examples $ xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 744 2 r----- 16098.9 ce 1 256 1 -b---- 342.5 -- Tomas Kouba |
|
From: Bryan D. P. <br...@th...> - 2006-06-30 01:40:49
|
> I don't have time to dig any deeper, but at least we know it > doesn't work > out of the box. Thanks for the info. Looks like one more thing for the todo list :-) -bryan - Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org |
|
From: Steve B. <st...@at...> - 2006-06-29 20:39:32
|
Brian, Per our earlier email exchange, I did a quick test of XenAccess by trying to get a module list from an HVM domU. I'm using an Intel VT chip (Pentium 930D) and ran a Knoppix 5 DVD as the guest OS. As suspected, things didn't work out very well: # ./run ./module-list libvir: Xen Daemon error : internal error domain information incomplete, missing kernel ERROR: failed to get domain info for domain id 1 ERROR: could not get kernel name for domain id 1 failed to init XenAccess library: bad address I don't have time to dig any deeper, but at least we know it doesn't work out of the box. - Steve Stephen Brueckner, ATC-NY |
|
From: Bryan D. P. <br...@th...> - 2006-06-28 18:42:05
|
> That worked like a charm, thank you! I can now successfully use your > module-list and process-list examples, and sure enough they match what is > reported inside the VM using lsmod and ps. Very slick. Excellent. > However, your process-data example only partially works for me (note I > modified it to take the pid as a command line argument): > > [root@localhost examples]# ./run ./process-data 1 Memory descriptor > addresses for pid = 1: > start_code = 0xffffffff > end_code = 0xc035ac8c > start_data = 0xc035ac8c > end_data = 0x00000001 > start_brk = 0xdead4ead > brk = 0xffffffff > start_stack = 0xffffffff > arg_stack = 0xc035aca4 > arg_end = 0xc035aca4 > env_start = 0x0000008e > env_end = 0x00000017 > ERROR: cannot translate this address > failed to map memory: Success > > Notwithstanding the fact that I'm no kernel guy so I can't make sense of the > above output from the printaddr() function (but it does look a little odd to > me), I see that the attempt to "/* grab the memory...and print it out */" > fails (with an error code of "Success"?). Do you have any thoughts on this? Yes. This is a side effect of the current test code being very kernel version specific. Basically, I've hard coded offsets into the kernel memory space where I expect to find the data. Of course, these offsets are dependant on kernel version, and even the options you use to compile the kernel. Very ugly. I'm in the process of thinking about more general solutions to this problem, so hopefully this will go away down the road. For now, it does look like the introspection technique is working on your machine...it's just the specific test program that is a little broken. In the future, I imagine that XenAccess will be able to dynamically locate kernel data structures at runtime, eliminating the need for static offsets. > As an unrelated question, do you think XenAccess would also work on Linux > running in an HVM domU? My testing so far has been in a paravirtualized > domU. Unfortunately, I don't have easy access to HVM hardware so I haven't been able to test this out. I'm not really sure if it would work "out of the box" or, if not, how many changes would be needed to get it working. If you are able to test it out, I'd certainly be interested in hearing the results. -bryan |
|
From: Steve B. <st...@at...> - 2006-06-28 16:13:29
|
Bryan D. Payne wrote: > This looks like libvirt cannot connect to the Xend deamon. I believe > that libvirt requires the xend-http-server to be enabled (which is no > longer the default setting for Xen). Try adding or uncommenting the > following line from /etc/xen/xend-config.sxp: > > (xend-http-server yes) > > After the edit you will need to restart xend: > > service xend restart > > I believe that this will fix your problem. I should probably add > something about this to the README file :-) Let me know how it works > out for you. That worked like a charm, thank you! I can now successfully use your module-list and process-list examples, and sure enough they match what is reported inside the VM using lsmod and ps. Very slick. However, your process-data example only partially works for me (note I modified it to take the pid as a command line argument): [root@localhost examples]# ./run ./process-data 1 Memory descriptor addresses for pid = 1: start_code = 0xffffffff end_code = 0xc035ac8c start_data = 0xc035ac8c end_data = 0x00000001 start_brk = 0xdead4ead brk = 0xffffffff start_stack = 0xffffffff arg_stack = 0xc035aca4 arg_end = 0xc035aca4 env_start = 0x0000008e env_end = 0x00000017 ERROR: cannot translate this address failed to map memory: Success Notwithstanding the fact that I'm no kernel guy so I can't make sense of the above output from the printaddr() function (but it does look a little odd to me), I see that the attempt to "/* grab the memory...and print it out */" fails (with an error code of "Success"?). Do you have any thoughts on this? As an unrelated question, do you think XenAccess would also work on Linux running in an HVM domU? My testing so far has been in a paravirtualized domU. Thanks for your help, - Steve Stephen Brueckner, ATC-NY |
