From owner-freebsd-current@FreeBSD.ORG Tue Mar 30 18:28:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B9B8106564A for ; Tue, 30 Mar 2010 18:28:33 +0000 (UTC) (envelope-from drbaud@yahoo.com) Received: from web65606.mail.ac4.yahoo.com (web65606.mail.ac4.yahoo.com [76.13.9.74]) by mx1.freebsd.org (Postfix) with SMTP id C24E98FC0A for ; Tue, 30 Mar 2010 18:28:32 +0000 (UTC) Received: (qmail 22867 invoked by uid 60001); 30 Mar 2010 18:28:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1269973711; bh=6GDyafb90DLxMzcUuaLLnczPN6YTYDB28SPw9IdvvCc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ltPoWwJxIakqUI1YUWNfomz1HEuhw8fKAJeEgxbLKDuaiyDV+dEl9eJtpzmR6HTf2deGmOIbzZSrBAuiQvCDcUA6eGl96cYbrDnsVrjkuH3ZL9yJ6QDVpuUryMuXLe5l2IDs7NF8WM9aQ/VoP2swFW+XuFY8uGMiKX155f/Mm1o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=URWqgDIios/l8afKNMqruhWpNQZT5Z/7LXk7oojf9UK8c4RUhOj8237vjfHyrc9b99ndrMY13B2PS+IeQdBghCehR4IRwKEsX9PKCnlQGH/fDEqKLYzUpDet2hGWGgJvt4h6i9GztrZIPoXbC7Co16Gyq43nPmOz6G9RfgWDZzQ=; Message-ID: <925011.22864.qm@web65606.mail.ac4.yahoo.com> X-YMail-OSG: wm5L3CUVM1kjQUj0SmLMU_jtoOoPNOCYPI800N4HA1cpWt2 ofldpV5FBkLtcNWWPO3e7moCDl4RU78Qn4Uie0.pTotgeI44QZuZhcDY0eY0 GMtWB5LypZJgg6FQKyZ5dJn4NpstZ.puCJijfJxpdptGeZyzGAgIGaeio4YV SIAkq6hUN5d8iQ69tfEqrdFnLs.CyBGapzskl0NV1231gNHDkTfDL98tKT0H Q8VkFkU9uOekLsl6CnNfUoy.ZWY6.VatxlgcyKiUrEBUrCseKEkg6eLRaTmL 2NjtcPmQcw.NrwhbQjd2pwaOSxJsZX.s6gqoyFjhoKA9Fq2SmAStC4BiUsOH k Received: from [64.238.244.146] by web65606.mail.ac4.yahoo.com via HTTP; Tue, 30 Mar 2010 11:28:31 PDT X-Mailer: YahooMailClassic/10.0.8 YahooMailWebService/0.8.100.260964 Date: Tue, 30 Mar 2010 11:28:31 -0700 (PDT) From: "Dr. Baud" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 30 Mar 2010 18:31:50 +0000 Subject: Re: pmap_extract question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 18:28:33 -0000 =0A It was pointed out that you need to pass physical address to mmap. A = step was missed in posted recipe. Consider that the return from vtophys(mem= ory_chunk) was passed at the offset parameter. Sorry for the confusion.=0A= =0A--- On Tue, 3/30/10, Dr. Baud wrote:=0A=0A> From: Dr.= Baud =0A> Subject: pmap_extract question=0A> To: freebsd= -current@freebsd.org=0A> Date: Tuesday, March 30, 2010, 12:35 PM=0A> =0A> = =A0 =A0 Say I have a kernel module that allocates a=0A> contiguous chunk of= kernel physical memory (note that a call=0A> to vtophys() reports a non-ze= ro value):=0A> =0A> memory_chunk =3D contigmalloc(=A0 =A0=0A> memory_chunk_= length,=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0=0A> NULL,=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0=0A> M_NOWAIT,=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=0A> 0UL,=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> ~0UL,=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> PAGE_SIZE,=0A> =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0);=0A> =0A> =A0 =A0 Th= e kernel virtual address returned from=0A> contigmalloc is passed to a user= application which maps the=0A> chunk to the virtual address space of the a= pplication:=0A> =0A> fd =3D open("/dev/mem", O_RDWR);=0A> mapped_memory_chu= nk =3D mmap( NULL,=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 = =A0 =A0=0A> memory_chunk_length,=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> = =A0 =A0 =A0 =A0 =A0 =A0 PROT_READ |=0A> PROT_WRITE,=0A> =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0 MAP_SHARED,=0A> =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0 fd,=0A> =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0 (off_t)=0A> memory_chunk);=0A> =0A> = =A0 =A0 Now consider that the mapped memory chunk=0A> address is then passe= d back to the kernel module. My=0A> question is; shouldn't pmap_extract(9) = be able to determine=0A> the physical address?=0A> =0A> struct thread *td = =3D curthread;=0A> pmap_t pmap =3D=0A> &td->td_proc->p_vmspace->vm_pmap;=0A= > physical_address =3D pmap_extract(pmap,=0A> mapped_memory_chunk);=0A> =0A= > =A0 =A0 In this example pmap_extract returns 0. Note=0A> also that /proc/= /map indicates the page(s)=0A> associated with the virtual addresses a= re not resident,=0A> e.g.:=0A> =0A> 0x801731000 0x801732000 0 0 0xffffff01d= 1ecd360 rw- 10 0=0A> 0x1000 NCOW NNC device -=0A> =0A> =A0 =A0 The first tw= o values shown are the start=0A> (address returned from mmap above) and end= addresses. The=0A> third, in this case zero, is intended to represent whet= her=0A> the pages are in resident. This value is simply the result=0A> of a= call to pmap_extract.=0A> =0A> =A0 =A0 Is this to be expected? Should mmap= (2) serve=0A> up a virtual address which pmap_extract cannot determine the= =0A> physical address? Or is there a flaw in this logic?=0A> =0A> =A0 =A0 T= hanks in advance......=0A> =0A> =A0 =A0 Dr=0A> =0A> =0A> =0A> =0A> =0A> =A0= =A0 =A0 =0A> =0A=0A=0A