From owner-freebsd-arch@freebsd.org Thu Apr 21 06:11:35 2016 Return-Path: Delivered-To: freebsd-arch@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 030E6B17AED for ; Thu, 21 Apr 2016 06:11:35 +0000 (UTC) (envelope-from pagaled1@saifunguo.com) Received: from m97115.qiye.163.com (m97115.qiye.163.com [220.181.97.115]) by mx1.freebsd.org (Postfix) with ESMTP id 5537116AA for ; Thu, 21 Apr 2016 06:11:29 +0000 (UTC) (envelope-from pagaled1@saifunguo.com) Received: from pagaled1$saifunguo.com ( [218.17.44.42] ) by ajax-webmail-wmsvr11 (Coremail) ; Thu, 21 Apr 2016 13:53:28 +0800 (CST) X-Originating-IP: [218.17.44.42] Date: Thu, 21 Apr 2016 13:53:28 +0800 (CST) From: pagaled1 To: freebsd-arch@FreeBSD.org Subject: Enquiry Paragliding X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20150911(74783.7961) Copyright (c) 2002-2016 www.mailtech.cn 163-hosting MIME-Version: 1.0 Message-ID: <2e30a0a1.a2fb.15437615df3.Coremail.pagaled1@saifunguo.com> X-CM-TRANSID: c+CowECpIUTYahhXVqgCAA--.1687W X-CM-SenderInfo: hzruzv2s6vtx5ixqw33rof0z/1tbiRBpSLlbdFB7SuQABsJ X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 06:11:35 -0000 RGVhciBDRU8sCiAgICAgICAKUGxlYXNlIHNlZSB0aGUgYXR0YWNobWVudCBvZiBQYXJhZ2xpZGlu Zy4KCgoKCi0tCgpCZXN0IHJlZ2FyZHMKCgoKClVzaGVyIENhZ2UKClRlbKO6IDAwODYtNzU1LTM2 NjIxNzM2CgpNb2IgIDowMDg2LTE1OSA4OTQ0IDExNzUKCkUtbWFpbDogYWRtaW5AcGFnYWxlZC5j b20KCiAgICAgICAgICAgICB1c2hlckBwZWdhbGVkLmNvbQ== From owner-freebsd-arch@freebsd.org Fri Apr 22 19:01:46 2016 Return-Path: Delivered-To: freebsd-arch@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 B78C4B192D5 for ; Fri, 22 Apr 2016 19:01:46 +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 92F8519C6 for ; Fri, 22 Apr 2016 19:01:46 +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 4C0D6B96C for ; Fri, 22 Apr 2016 15:01:45 -0400 (EDT) From: John Baldwin To: 'freebsd-arch' Subject: bus_map_resource Date: Fri, 22 Apr 2016 11:54:53 -0700 Message-ID: <4660875.ZpJTJgz4hU@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) 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); Fri, 22 Apr 2016 15:01:45 -0400 (EDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 19:01:46 -0000 Yet another extension I've long wanted to make to new-bus is to split out the part of bus_activate_resource() that establishes a valid mapping for use with bus_space_* (or the bus_* wrappers) from activating / detactivating. In particular, making a resource "active" is orthogonal to having a mapping (e.g. for a PCI BAR, a resource is "active" if the appropriate IO or mem decoding bit is set in the device's command register. Whether or not the CPU has a valid mapping for that range doesn't matter). Secondly, there is a need to be able to specify optional parameters of mappings. Some drivers may wish to only map a portion of a resource instead of all of it (e.g. the AGP driver wishes to only map the first page of the aperture instead of all of the aperture to avoid wasting a lot of KVA on 32- bit systems). Some drivers may wish to map a memory resource with non-default memory attributes (e.g. WC). I have a strawman with an implementation on x86 to permit this. In this model, a new RF_UNMAPPED flag is added that asks bus_activate_resource() to not setup the implicit mapping in 'struct resource'. Instead, a driver requests explicit mappings via bus_map_resource() and is responsible for calling bus_unmap_resource() to tear them down. A driver should allocate a 'struct resource_map' for each mapping (probably by putting it in its softc) and then passing a pointer to that object to both routines. This structure's members are named so that you can use the bus_* convenience API on it the same way you can with 'struct resource' for the implicit mapping. bus_map_resource() accepts an optional 'args' argument that defines optional properties of the mapping request. A driver can request a mapping of a subset of a resource or a specific memory attribute. The 'args' argument is defined as a structure headed by a size similar to the scheme Konstantin recently used for make_dev_s(). One use case for this is that I'd like to fix the NEW_PCIB bits in the PCI-PCI bridge driver to request a mapping in the subset of the resource on the "parent" bus for the mapping window used by a resource for a child device instead of passing up that child resource directly to the nexus. The idea is that any bus driver that creates its own rman and resources should not be passing those resources up to any of its parents. Another use case that would benefit from this are bridges that do address translations (such as the ThunderX Host-PCI bridge driver recently committed). It can allocate a resource from its parent representing the "parent" side of its resource window and request mappings for regions of that window corresponding to child resources when creating mappings of child resources. What I'd like feedback on now is the API. If we decide to go forward I would also like help fixing bus drivers to use this. Some sample code for mapping a resource that uses a WC mapping: struct foo_softc { ... struct resource *sc_regs_res; struct resource_map sc_regs; ... }; foo_attach(device_t dev) { struct resource_map_request args; ... sc->sc_regs_res = bus_alloc_resource(dev, ..., RF_ACTIVE | RF_UNMAPPED); resource_init_map_request(&args, sizeof(args)); args.memattr = VM_MEMATTR_WRITE_COMBINING; error = bus_map_resource(dev, SYS_RES_MEMORY, sc->regs_res, &args, &sc->sc_regs); ... } foo_something(struct foo_softc *sc) { x = bus_read_4(&sc->sc_regs, MY_CSR); } foo_detach(device_t dev) { bus_unmap_resource(dev, SYS_RES_MEMORY, sc->regs_res, &sc->sc_regs); bus_release_resource(dev, SYS_RES_MEMORY, rman_get_rid(sc->regs_res), sc->regs_res); } There is a review with the current WIP code that includes the API and an implementation for x86. It does not yet have manual page updates. https://reviews.freebsd.org/D5237 -- John Baldwin From owner-freebsd-arch@freebsd.org Fri Apr 22 19:33:59 2016 Return-Path: Delivered-To: freebsd-arch@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 56E62B19D84 for ; Fri, 22 Apr 2016 19:33:59 +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 398201B7F for ; Fri, 22 Apr 2016 19:33:59 +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 17768B93A for ; Fri, 22 Apr 2016 15:33:58 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: Starting APs earlier during boot Date: Fri, 22 Apr 2016 12:33:49 -0700 Message-ID: <1797307.a21JNIcVnp@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <1730061.8Ii36ORVKt@ralph.baldwin.cx> References: <1730061.8Ii36ORVKt@ralph.baldwin.cx> 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); Fri, 22 Apr 2016 15:33:58 -0400 (EDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 19:33:59 -0000 On Tuesday, February 16, 2016 12:50:22 PM John Baldwin wrote: > Currently the kernel bootstraps the non-boot processors fairly early in the > SI_SUB_CPU SYSINIT. The APs then spin waiting to be "released". We currently > release the APs as one of the last steps at SI_SUB_SMP. On the one hand this > removes much of the need for synchronization while SYSINITs are running since > SYSINITs basically assume they are single-threaded. However, it also enforces > some odd quirks. Several places that deal with per-CPU resources have to > split initialization up so that the BSP init happens in one SYSINIT and the > initialization of the APs happens in a second SYSINIT at SI_SUB_SMP. I've posted a review of the final set of changes here: https://reviews.freebsd.org/D6069 To permit a smoother transition, the earlier startup is temporarily controlled by a kernel option (EARLY_AP_STARTUP) so that it can be easily disabled if there are regressions and to allow individual platforms to have time to port over. My plan is to enablet his by default on x86 once it is in the tree. I would like to have all platforms cut over for 11.0. -- John Baldwin From owner-freebsd-arch@freebsd.org Sat Apr 23 12:37:03 2016 Return-Path: Delivered-To: freebsd-arch@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 52DA8B1A865 for ; Sat, 23 Apr 2016 12:37:03 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 354061680 for ; Sat, 23 Apr 2016 12:37:03 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3489FB1A864; Sat, 23 Apr 2016 12:37:03 +0000 (UTC) Delivered-To: arch@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 34321B1A863 for ; Sat, 23 Apr 2016 12:37:03 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0749F167F for ; Sat, 23 Apr 2016 12:37:03 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: by mail-io0-x235.google.com with SMTP id f89so116228478ioi.0 for ; Sat, 23 Apr 2016 05:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8YgSctm7qa9iAZgBdaLfG5nT3o0liD02A9xkuTYTd+g=; b=kHTfQkeWwTtUkiBjqCnctgiuZMZhHs3W5sJTwLRdb5eMr9E7d70fgLZwpIysSa7pEa AUPtN+s7kX25kk4fmPUtFV3UupYqw94mMLC7z/MyCcBFbpkrlVmADAqQwNPqVAQVrKsh TljyLcoztHn+aRJ6W9ZpYAoslCRUOzKS/gsEmUvhmIlB5qcNIhTbrBTpDNog4iSJ1IbT nF2rp6FhwTYnqz1/iqkHBcpXWumVMzj4vuuhtyLmWo2CW1iVZJ5XWZwZ/v7e/cdt537T iqeILlQjbVzWoCrn8dvQSB3ceAgb2738x0PyihqQm5Sk79vKTBPPUWGc0c3vggSNEdz6 Kizw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8YgSctm7qa9iAZgBdaLfG5nT3o0liD02A9xkuTYTd+g=; b=fX9qa1g8ZoDnKUnadfYE9oe0BWgmZrwbnUXF1WrhsfjSF3BsgZfN62AI3QI7zYLb8i oy2coSFefCVwPpIYbNBZY2xiwa254D71I5n7/ojGRkHI/zTCwznoblyouIaAFpYheZrK zv+2HOaO+ewKF2edDZdyr2lQlpJzl18T/dElDA8L7J612keGPHpj3k5kVQc4QFq0ey6N f3AGwScfXpYRK73En+u3LlUzE5pLbRysEqZ7SgZ7G/Eb9yZomC4eJdJ/R3/qr0jwRLPM E8uwsNdYQgldsK8zRx8nLAWHU91gUY+pYV2JuxLcGbDJT9PZMS9vZAT6Us2971IpoTk4 mToQ== X-Gm-Message-State: AOPr4FWoaoNGX4Z1DoJWYUp7PsAhyQk8dZ4YDHrT7jPo3DD7YBxU+ZnYFNybbMssLbZmP2KzuT/EMKgx0Dln1g== X-Received: by 10.107.7.72 with SMTP id 69mr10914247ioh.64.1461415022358; Sat, 23 Apr 2016 05:37:02 -0700 (PDT) MIME-Version: 1.0 References: <20160310155121.GA1741@kib.kiev.ua> <20160327175943.3749400b@fabiankeil.de> In-Reply-To: <20160327175943.3749400b@fabiankeil.de> From: Howard Su Date: Sat, 23 Apr 2016 12:36:52 +0000 Message-ID: Subject: Re: Call for testing - ASLR patch To: Fabian Keil Cc: arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 12:37:03 -0000 This works for me for couple of days. Will this hit 11.0? On Mon, Mar 28, 2016 at 12:05 AM Fabian Keil wrote: > Konstantin Belousov wrote: > > > I have a small and straightforward yet feature-packed patch to > > implement ASLR for FreeBSD available for broader testing. The patch > > can be fetched from https://www.kib.kiev.ua/kib/aslr/aslr.5.patch . > > Awesome. I've been using the patch on a couple of amd64 > systems and haven't noticed any problems so far. > > Fabian > -- -Howard