All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <aliguori@us.ibm.com>
To: "Bryan D. Payne" <bryan@thepaynes.cc>
Cc: xen-devel@lists.xensource.com
Subject: Re: viewing memory in domU
Date: Mon, 31 Oct 2005 19:31:45 -0600	[thread overview]
Message-ID: <4366C581.3080303@us.ibm.com> (raw)
In-Reply-To: <036E9E94-EF34-4AB3-9A57-B00050C8FD83@thepaynes.cc>

Bryan D. Payne wrote:

> I'm looking at developing an application to run in dom0 that will  
> need a view into the memory of machines in domU.  For now it will be  
> a read-only view, but I'd like to experiment with read-write later.   
> I've done some poking around in the source code and found the  
> xc_map_foreign_range function in libxc.  From what I could tell, this  
> is (at least one way) how to do this.  So, a couple of questions:

Yup, this is the right function to use.

> * This function doesn't seem to be used very much.  The only usage  
> that I could find was in the XenTrace tool.  So I just wanted to  
> confirm that this function was still maintained and not getting ready  
> to go away with the 3.0 changes.

Yup, it's critical for both domain creation and save/restore.  See 
libxc/xc_linux_build.c or libxc/xc_linux_save.c for other examples of use.

> * Is there any reason that this functionality isn't implemented in  
> the lowlevel/xc library in python?  Perhaps just because there isn't  
> as much demand for it?  Or is there a deeper implementation issue?

Things that are that low-level are usually performance sensitive (like 
migration) so we implement it in C.  Plus, I think it's non-trivial to 
expose raw memory to Python (with doing a copy).

> * Are there other ways to view the memory of domU machines?   
> Similarly, are there any ways to view items such as CPU registers of  
> the domU machines?

No, xc_map_foreign_range is The Way.  You can get the register state of 
a domU via xc_domain_get_vcpu_context().

> * Given that the type of usage that I have in mind is going to be  
> somewhat high bandwidth (i.e., need to constantly read and re-read  
> memory on the domU machine(s)), is this function the best way to go?   
> Or would you recommend that I look into another way?

xc_map_foreign_range() actually maps the physical page into dom0's 
address space.  You're limited by the virtual address space available in 
dom0 (so you may have to remap portions of the domUs memory into your 
window) but there shouldn't be any performance overhead once it's mapped.

Regards,

Anthony Liguori

> Thanks for the help!
>
> -bryan
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>  
>

      reply	other threads:[~2005-11-01  1:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-01  0:46 viewing memory in domU Bryan D. Payne
2005-11-01  1:31 ` Anthony Liguori [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4366C581.3080303@us.ibm.com \
    --to=aliguori@us.ibm.com \
    --cc=bryan@thepaynes.cc \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.