From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 1 09:12:59 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22251DF0; Wed, 1 Oct 2014 09:12:59 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A431D300; Wed, 1 Oct 2014 09:12:58 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s919CqT7008194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2014 12:12:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s919CqT7008194 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s919Cqtl008193; Wed, 1 Oct 2014 12:12:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 1 Oct 2014 12:12:52 +0300 From: Konstantin Belousov To: leon zadorin Subject: Re: does linsysfs support mmap on pci resources (e.g. pci device's registers etc.) Message-ID: <20141001091252.GP26076@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-emulation@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 09:12:59 -0000 You choice of the list to ask the question is weird. I added hackers@ as more suitable ML. On Wed, Oct 01, 2014 at 03:44:48PM +1000, leon zadorin wrote: > Hello everyone, > Sorry if this is a bit of a noob question -- I'm just starting on this > topic... does FreeBSD's emulation of sysfs (from linux world) support > "mmap" on pci resources? > > Something similar to the following in the linux environment: > > fd = open("/sys/devices/pci0001\:00/0001\:00\:07.0/resource0", O_RDWR | O_SYNC); > ptr = mmap(0, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); > printf("PCI BAR0 0x0000 = 0x%4x\n", *((unsigned short *) ptr); > > (above taken from > http://billfarrow.blogspot.com.au/2010/09/userspace-access-to-pci-memory.html) > > The reason I am asking is because I would like to map pci device > registers/memory in user space (and read/write some of the device's > registers from userspace). The reasons are auxiliary to this post > (e.g. kernel-bypass, system call bypass, etc.) At this stage it would > suffice to simply accept that user space pci-register access is needed > without paying the price of any system/ioctl/etc. call on every > access-instance to device's config/control register(s). > > I would prefer to avoid writing additional explicit (albeit generic) > pci related kernel module in order to provide "mmapping" of the given > pci resources to userspace if there is already such a generic way to > do it via sysfs "syntax" (I would like to reduce any of the > specific/additional code re-writing at the kernel level as much as > possible). AFAIK, there is no facilities in FreeBSD kernel which allow you to get the configuration registers or memory BARs mmapped into the userspace. The linsysfs is out of question for this sort of hacks. The native FreeBSD' /dev/pci does not support mmaping either. It should be not too hard to extend the /dev/pci to do what you described. Start looking at the sys/dev/pci/pci_user.c PCIe configuration window is active, so you could access it by hand by mmapping /dev/mem. Also, the window is mapped into KVA, so you could access it by /dev/kmem as well. /dev/mem would be easier, I think, because it needs the physical address, which can be learned from ACPI MCFG much easier than the value of the static symbol pcie_base.