Rob Gardner
2006-Mar-08 20:16 UTC
[Xen-devel] Trace buffers no longer working -- What changed?
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
Rob Gardner
2006-Mar-08 22:25 UTC
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@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2006-Mar-08 23:57 UTC
Re: [Xen-devel] Trace buffers no longer working -- What changed?
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel