Re: Trace buffers no longer working -- What changed? **Found the problem

[Rob Gardner <rob.gardner@hp.com>]

To follow up on my own post, I discovered that the mapping is failing in 
xen, in do_mmu_update, because the call to set_foreigndom() fails. This 
shouldn't happen, as (I think) it is perfectly valid for dom0 to map 
pages into its own space. The set_foreigndom() routine was changed 
recently to disallow the case where a domain tries to sepcify itself as 
a foreign domain. The comment on the changeset (8792) says "it must use 
DOMID_SELF". Fair enough, it sounds like xentrace and xenmon should use 
DOMID_SELF instead of just "0" for the domain id; But then in 
direct_remap_pfn_range() in the xen0 linux kernel 
(arch/i386/mm/ioremap-xen.c) there is code that check to make sure domid 
is *not* DOMID_SELF. So we need an executive decision on how this should 
be handled. Should direct_remap_pfn_range() be fixed, or was the change 
in set_foreigndom() incorrect?

As a crude workaround to anybody who wants to use xentrace and/or 
xenmon, just remove the line "okay = 0" like so:

diff -r b41ad96f1242 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c    Tue Mar  7 15:48:36 2006
+++ b/xen/arch/x86/mm.c    Wed Mar  8 15:22:06 2006
@@ -1669,7 +1669,6 @@
     {
         MEM_LOG("Dom %u tried to specify itself as foreign domain",
                 d->domain_id);
-        okay = 0;
     }
     else if ( !IS_PRIV(d) )
     {



Rob




Rob Gardner wrote:

> It has come to my attention that Xenmon and xentrace have stopped 
> working in the latest xen-unstable tree, but I'm not sure precisely 
> when this happened. The problem is that both utilities are failing to 
> map the xen trace buffers into user space. Anyone have any idea what 
> might have changed recently that could have caused this? The trace 
> buffer allocation code in the hypervisor is using 
> alloc_xenheap_pages() followed by SHARE_PFN_WITH_DOMAIN(), and then 
> the userland apps use xc_map_foreign_range() to get access to the 
> trace buffers. xc_map_foreign_range() uses ioctl(IOCTL_PRIVCMD_MMAP) 
> which is failing with errno 14 (bad address). In particular, the 
> privcmd ioctl uses direct_remap_pfn_range() which is actually 
> returning the error. I kind of suspect that there's nothing wrong at 
> the userland side of things, but something is going wrong when the 
> memory is allocated and "shared". Can anybody help?
>
> Rob
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel