From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Gardner Subject: Re: Trace buffers no longer working -- What changed? **Found the problem Date: Wed, 08 Mar 2006 15:25:57 -0700 Message-ID: <440F59F5.2090001@hp.com> References: <440F3B89.3020009@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <440F3B89.3020009@hp.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel List-Id: xen-devel@lists.xenproject.org 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