From owner-freebsd-current@FreeBSD.ORG Thu Feb 2 22:21:25 2006 Return-Path: X-Original-To: freebsd-current@www.freebsd.org Delivered-To: freebsd-current@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9FC716A420 for ; Thu, 2 Feb 2006 22:21:25 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4168F43D45 for ; Thu, 2 Feb 2006 22:21:25 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id k12MLOTt008836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Feb 2006 17:21:24 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k12MLI0o070669; Thu, 2 Feb 2006 17:21:18 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17378.34270.630897.473143@grasshopper.cs.duke.edu> Date: Thu, 2 Feb 2006 17:21:18 -0500 (EST) To: freebsd-current@www.freebsd.org X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: Subject: mapping "random" physical memory into kernel 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: Thu, 02 Feb 2006 22:21:25 -0000 Can somebody please remind me what the supported way to establish a kernel virtual address for a "random" chunk of physical memory is? I'm currently using pmap_mapdev() directly, but that just feels dirty... I need to twiddle the settings of an Nvidia NF4 bridge in extended PCI config space (offset 0x178). These offsets are not accessible via normal pci config space writes, but are doable when you use the 0xe000000 mapping. The problem is that this memory is not really associated with anything, so a normal bus_alloc_resource() allocation doesn't seem like it would work. Thanks, Drew