From owner-freebsd-hackers@freebsd.org Sun Jul 3 19:37:28 2016 Return-Path: Delivered-To: freebsd-hackers@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 C5939B90B8E for ; Sun, 3 Jul 2016 19:37:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 936D521BC; Sun, 3 Jul 2016 19:37:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x230.google.com with SMTP id g13so137407693ioj.1; Sun, 03 Jul 2016 12:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BDvzoTm8PMvSDcU2jfKDHIPOKMsfMHdc1yat19v2TpQ=; b=0WHFKMVgw+UY27TyyQt2SySIU6TN6gRN2azg8VppIH3Yb75GZraA15/S0j4ewRGVTe dnXRd0QmW1a2jUWRngAmgzJPKraF1DEqmcmqr2GNnjKmM6v85csTuFWgwaPNAdF1dorW Xf396ee6Ogy6T3oIFV88zAgsIRQ+CpoM0O0nfnRlPOqiROsDJdHGJdDl44Ixzmijzu1l EUnaXeXSEzQ9XTdsbsqgqElxJqxpz8vak7UUCCKwXDMbDFZNceNN2l8XO5CaX84rBAsC gtgGg+U4GHxuzjfH6Kmhd49LWfzCIQa527GAu9SI9Lw08LwIKlQb661eBOvmDTY71XvH Z2IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BDvzoTm8PMvSDcU2jfKDHIPOKMsfMHdc1yat19v2TpQ=; b=KbLZlwB8PoEgvteTd42ej0f67uLArmoLLrmcepScHr17nqJR3mdKmg611TYpo6yiM2 swGJp4NReoGp51rzn77IMdBuGQGXiF8wenoOylVWJDHe3lCWTaGZ3XjLT+suxYRImd3j KXxuch/IXObZP8udMgMa7MEhSbbiZmQpPe5dEC1L9FCSXub36X3P4EhhPVDxPmYASP/c 6Eio4RG5mmrmwXCsUZZmLvakYkMnu8mdf70HZVoZ4jI3PYpBBWT1109IEEyi2BewTRtR D/z/Fqj5QUySN7x5hV4R1WKQvwxvIcVPWM4NSv9VXA/0uMVMzR/bu4vEqRluJYbdoEiL sLUA== X-Gm-Message-State: ALyK8tLIFAWUXJ7d3EK1bNeVEMstpb/gkvyxs1DE2MWwWHH1uLc0/0jJDKsvgFY68UW+bv+3+5fievJsUzbVGw== X-Received: by 10.107.144.86 with SMTP id s83mr5793822iod.165.1467574647939; Sun, 03 Jul 2016 12:37:27 -0700 (PDT) MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.36.210.212 with HTTP; Sun, 3 Jul 2016 12:37:27 -0700 (PDT) In-Reply-To: <5345fb94-91b8-5019-037e-d4825a694cfd@freebsd.org> References: <57761101.3030101@freebsd.org> <5345fb94-91b8-5019-037e-d4825a694cfd@freebsd.org> From: Adrian Chadd Date: Sun, 3 Jul 2016 12:37:27 -0700 X-Google-Sender-Auth: hmGAQPKUi-aXkQZh1CznYJTojpg Message-ID: Subject: Re: Review request: sparse CPU ID maps To: Nathan Whitehorn Cc: outro pessoa , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 19:37:28 -0000 On 2 July 2016 at 17:08, Nathan Whitehorn wrote: > A reasonable first pass at checking for this kind of bug is doing grep -lR > '< mp_ncpus'. Running that on sys/arm and sys/arm64 shows the following > files: > arm/mv/armadaxp/armadaxp_mp.c > arm/include/counter.h > arm/broadcom/bcm2835/bcm2836.c > arm/broadcom/bcm2835/bcm2836_mp.c > arm/freescale/imx/imx6_mp.c > arm/allwinner/aw_mp.c > arm/rockchip/rk30xx_mp.c > arm/amlogic/aml8726/aml8726_mp.c > arm/samsung/exynos/exynos5_mp.c > arm/arm/mp_machdep.c > arm/nvidia/tegra124/tegra124_mp.c > arm64/include/counter.h > arm64/arm64/gic_v3.c > arm64/arm64/gic_v3_its.c > arm64/arm64/gicv3_its.c > > All of them should, in some sense, be CPU_FOREACH(), but it may not matter. > For example, it may not be possible to have sparse CPU IDs on some or all of > those SOCs. At least the generic ones (counter, mp_machdep.c, gic (why are > there both gic_v3_its.c and gicv3_its.c?)) should be changed, I think. > -Nathan I think converting all the users over to the CPU_FOREACH thing is the right way to go, even if the SOC doesn't require it. People do bring up new systems by copy/pasta'ing an existing similar system, so we're best served by having all the consumers migrated. But, I'd do it in head/12. Early in head/12. :-P -adrian