Trace buffers no longer working -- What changed?

Trace buffers no longer working -- What changed?

[Rob Gardner]

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

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

[Rob Gardner]

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

Re: Trace buffers no longer working -- What changed?

[Keir Fraser]

On 8 Mar 2006, at 20:16, 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?

Should be fixed now (changeset 9176).

  -- Keir