Date: Mon, 4 Apr 2016 11:42:00 -0700 From: "Lundberg, Johannes" <johannes@brilliantservice.co.jp> To: "freebsd-x11@freebsd.org" <freebsd-x11@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: EGL driver for vt? Message-ID: <CAASDrVkKAUJz_WyDMYKdRBUDa45KVb5iYvv27gobuf8JbiFqOg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
SGkNCg0KV291bGQgYW55b25lIGJlIGludGVyZXN0ZWQgaW4gYW4gTWVzYS9FR0wgZHJpdmVyIGZv ciB2dD8NCg0KSWYgd2UgaGFkIHRoaXMgd2UgY291bGQgcnVuIHdheWxhbmQvZWdsLWJhc2VkIGNv bXBvc2l0b3JzIHdpdGggbGx2bXBpcGUgb24NCnBsYXRmb3JtcyB3aXRob3V0IEdQVSBzdXBwb3J0 IHNpbWlsYXIgdG8gWCtzY2ZiIGRyaXZlci4gKGlmIG15DQp1bmRlcnN0YW5kaW5nIG9mIHRoZSBn cmFwaGljcyBzdGFjayBpZiBjb3JyZWN0Li4pDQoNCklmIHNpbWlsYXIgdG8gdGhlIChub3cgZGVw cmVjYXRlZCkgTGludXggZnJhbWVidWZmZXIgZHJpdmVyIGluIE1lc2EgSSBndWVzcw0KaXQgd291 bGQgbm90IGJlIHRoYXQgbXVjaCB3b3JrIHRoYXQgaGFzIHRvIGJlIGRvbmUuIG1lc2EvbGx2bXBp cGUgd291bGQgZG8NCmFsbCB0aGUgaGVhdnkgbGlmdGluZywgY29ycmVjdD8NCg0KVGhpcyB3b3Vs ZCBlbmFibGUgYSB3aG9sZSBsb3Qgb2YgbmV3IGV4Y2l0aW5nIHBvc3NpYmlsaXRpZXMgYW5kIHNv bHZlIHRoZQ0KcHJvYmxlbSB3aXRoIGxhY2sgb2YgR1BVIGRyaXZlcnMuLg0KDQpXaGF0IGRvIHlv dSB0aGluaz8NCgotLSAKPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LT0t PS09LT0tPS09LT0tCuenmOWvhuS/neaMgeOBq+OBpOOBhOOBpu+8muOBk+OBrumbu+WtkOODoeOD vOODq+OBr+OAgeWQjeWum+S6uuOBq+mAgeS/oeOBl+OBn+OCguOBruOBp+OBguOCiuOAgeenmOWM v+eJueaoqeOBruWvvuixoeOBqOOBquOCi+aDheWgseOCkuWQq+OCk+OBp+OBhOOBvuOBmeOAggrj goLjgZfjgIHlkI3lrpvkurrku6XlpJbjga7mlrnjgYzlj5fkv6HjgZXjgozjgZ/loLTlkIjjgIHj gZPjga7jg6Hjg7zjg6vjga7noLTmo4TjgIHjgYrjgojjgbPjgZPjga7jg6Hjg7zjg6vjgavplqLj gZnjgovkuIDliIfjga7plovnpLrjgIEK6KSH5YaZ44CB6YWN5biD44CB44Gd44Gu5LuW44Gu5Yip 55So44CB44G+44Gf44Gv6KiY6LyJ5YaF5a6544Gr5Z+644Gl44GP44GE44GL44Gq44KL6KGM5YuV 44KC44GV44KM44Gq44GE44KI44GG44GK6aGY44GE55Sz44GX5LiK44GS44G+44GZ44CCCi0tLQpD T05GSURFTlRJQUxJVFkgTk9URTogVGhlIGluZm9ybWF0aW9uIGluIHRoaXMgZW1haWwgaXMgY29u ZmlkZW50aWFsCmFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUuCkRpc2Nsb3N1 cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciBhbnkgb3RoZXIgYWN0aW9uIG9mIHVzZSBvZiB0 aGlzCmVtYWlsIGJ5IHBlcnNvbiBvdGhlciB0aGFuIGludGVuZGVkIHJlY2lwaWVudCwgaXMgcHJv aGliaXRlZC4KSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBhbmQgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluCmVycm9yLCBwbGVhc2UgZGVzdHJveSB0aGUgb3JpZ2luYWwg bWVzc2FnZS4K From owner-freebsd-current@freebsd.org Mon Apr 4 22:53:41 2016 Return-Path: <owner-freebsd-current@freebsd.org> Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6453B037AA for <freebsd-current@mailman.ysv.freebsd.org>; Mon, 4 Apr 2016 22:53:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C7851143B for <freebsd-current@freebsd.org>; Mon, 4 Apr 2016 22:53:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8BE74B95D; Mon, 4 Apr 2016 18:53:40 -0400 (EDT) From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: Konstantin Belousov <kostikbel@gmail.com>, Ryan Stone <rysto32@gmail.com> Subject: Re: accessing a PCIe register from userspace through kmem or other ways ? Date: Mon, 04 Apr 2016 15:45:07 -0700 Message-ID: <9376230.YZMFsgSvTf@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160401170458.GV1741@kib.kiev.ua> References: <CA+hQ2+iU4odjhaNicFA4QjvSZR2OZOOy+Fu4LTqsibdoK4M8zg@mail.gmail.com> <CAFMmRNxJDuQoC-YuwbaWkj7MGVw9UgPEANOX6bN=i8+p_9vm5w@mail.gmail.com> <20160401170458.GV1741@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 04 Apr 2016 18:53:40 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>; List-Post: <mailto:freebsd-current@freebsd.org> List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=subscribe> X-List-Received-Date: Mon, 04 Apr 2016 22:53:42 -0000 On Friday, April 01, 2016 08:04:58 PM Konstantin Belousov wrote: > On Fri, Apr 01, 2016 at 12:48:24PM -0400, Ryan Stone wrote: > > That is actually a really good question. I know that with some recent > > BIOSes if I enabled allocating 64-bit addresses to BARs, the BAR would > > actually be mapped outside of the range of /dev/mem. From a quick glance > > at libpciaccess, I don't think that it handles this case. A specific > > mechanism for allowing mmaping of BARs would be useful, I think. > > I am not sure what do you mean by 'outside of the range of /dev/mem'. > IMO /dev/mem (not kmem) handles every possible physical address both > for mmap(2) and for read(2)/write(2). For io interface there were > some bugs, but they are believed to be fixed. I mean amd64. I suspect Ryan might be referring to BARs outside of the DMAP which we only populate to Maxmem IIRC. /dev/mem should work for those. However, another question is how to deal with systems that do bus address translation (like the arm64 ThunderX boxes) where the values in the PCI BAR are not CPU physical addresses. To do this properly we may need some sort of bus method akin to my bus_map_resource() WIP but one that instead returns a suitable 'struct sglist' for a given 'struct resource *' that can be used with OBJT_SG to build a VM object to use for the mapping. (At some point I do think I would like a variant of OBJT_SG that used managed pages so that mappings could be revoked when whatever is backing the sglist is disabled (e.g. the device is ejected or the BAR is relocated, etc.).) -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAASDrVkKAUJz_WyDMYKdRBUDa45KVb5iYvv27gobuf8JbiFqOg>