[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Trace buffers no longer working -- What changed? **Found the problem



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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.