Re: [XenPPC] getdomaininfo_list() and xm top

2006-09-05 Thread Hollis Blanchard
Hi Tony, are you familiar with how the xencomm stuff works? It's pretty
straightforward: the kernel constructs a scatter/gather list containing
physical addresses to map virtual-contiguous userspace buffers. Those
lists are created in arch/powerpc/platforms/xen/hcall.c .

At first glance, it appears the DOM0_GETDOMAININFOLIST dom0 op is being
handled correctly, so it looks like you'll need to dig in to that a
little more.

On Tue, 2006-09-05 at 14:23 +1000, Tony Breeds wrote:
> Hi All,
>   I've been looking at the "xm top" command.  Currently this fails
> with "Failed to retrieve statistics from libxenstat".  libxenstat makes
> a getdomaininfo_list hypercall.  Doing a little digging it seems the
> copy_to_guest_offset() call (dom0_ops.c:437) is returning -EFAULT.
> 
> If I compare getdomaininfo with getdomaininfo_list it looks to me that
> the main difference is the destination for of the results.
> getdomaininfo(), overwrites the u_dom0_op of the hypercall
> getdomaininfolist(), places the results into a userspace buffer, whose
> address comes in via the u_dom0_op.
> 
> I've poked around in xencomm_copy_to_guest and it seems that all the
> addresses[] are XENCOMM_INVALID.  When makes be think that the address
> we're trying to write to is bogus for some reason.

*All* of them? You might see how many bytes xencomm_create() is
handling, since it only marks *unused* addresses as INVALID.

> I'm not really sure I know what my question is other than to ask for
> pointers on how narrow down what's missing on the ppc side to make this
> type of hypercall work.
> 
> I'm not sure I'm on the right track here but I don't think that we're
> passing copy_to_guest_offset(), a pointer that can successfully be cast
> as a xencomm_desc.

Try this to start:

diff -r 199b457c4325 drivers/xen/core/xencomm.c
--- a/drivers/xen/core/xencomm.cMon Aug 28 18:43:52 2006 -0500
+++ b/drivers/xen/core/xencomm.cTue Sep 05 10:51:02 2006 -0500
@@ -21,7 +21,7 @@
 #include 
 #include 

-int xencomm_debug;
+int xencomm_debug = 1;

 /* translate virtual address to physical address */
 static unsigned long xen_vaddr_to_paddr(unsigned long vaddr)

(Hmm, looks like all those printks are missing log levels. Patch would
be happily accepted. :)

-- 
Hollis Blanchard
IBM Linux Technology Center


___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel


[XenPPC] getdomaininfo_list() and xm top

2006-09-04 Thread Tony Breeds
Hi All,
I've been looking at the "xm top" command.  Currently this fails
with "Failed to retrieve statistics from libxenstat".  libxenstat makes
a getdomaininfo_list hypercall.  Doing a little digging it seems the
copy_to_guest_offset() call (dom0_ops.c:437) is returning -EFAULT.

If I compare getdomaininfo with getdomaininfo_list it looks to me that
the main difference is the destination for of the results.
getdomaininfo(), overwrites the u_dom0_op of the hypercall
getdomaininfolist(), places the results into a userspace buffer, whose
address comes in via the u_dom0_op.

I've poked around in xencomm_copy_to_guest and it seems that all the
addresses[] are XENCOMM_INVALID.  When makes be think that the address
we're trying to write to is bogus for some reason.

I'm not really sure I know what my question is other than to ask for
pointers on how narrow down what's missing on the ppc side to make this
type of hypercall work.

I'm not sure I'm on the right track here but I don't think that we're
passing copy_to_guest_offset(), a pointer that can successfully be cast
as a xencomm_desc.

Yours Tony

   linux.conf.au   http://linux.conf.au/ || http://lca2007.linux.org.au/
   Jan 15-20 2007  The Australian Linux Technical Conference!


___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel