Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1304450pxa; Sat, 15 Aug 2020 15:10:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyzS0ibXW45R/acrNx2zCqI6uU8zSde1cQRynWKtYFpAfBbc9b9pPkFpD7qM8xWGqN5teve X-Received: by 2002:a05:6402:3193:: with SMTP id di19mr8731192edb.224.1597529401375; Sat, 15 Aug 2020 15:10:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597529401; cv=none; d=google.com; s=arc-20160816; b=l8MDDzj9MOnAER46r/1r3hSRXfhJ+aD7MMP1pDRQozoechq8qy0p33b+OWS+YRueGO xYR82D2/hkh+PbHGlU55zVCoIrHHVQjZSvFDxs+sP76xPU+ny2MRSth0ZMSZx3YhUgFO /Z0nLDQZ4tfOJ1JQyO5ZbhnYi1Kpff5MfoFjmz922kKH/TShlXbr9+bIrHyqG/lBBQxz 9nSt/hT46Rc46aANr+n8qjN8l2bFlzcvkJ9OuNDyufJy4X+DNSsbdnNosslqmAWhr4kj aqEkLEzasZ/4oN8UL5tOuQpzmyVPARHOhpWh68L95l4hNv1UceJOMPKrMQwC9/TkRpzd kADg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=mqUm0D+LR1fyNqgEpWLZcUrJ5fpnGERJD73F5yobxbo=; b=heeNi39DCcwbpjyvc1INZDghegsO8zAI3tOO+air4cuxC+WlaZRSIgiRbvfaRgb+7N Nt1degkwT2JR+fa3FONSc9Dguu11SVvKtASvc/Cw+gLEwy0h7CJZJyur7gr17PEmIIy6 Z0ZAx6Gv3hPZ94zFOwEETBwD9lg6f/ighYwsig39HE64RWb3bNSh903m/7bSHBtH/3hb WIDs0EzfVBPrsF7Vj8eihd05yxrKBQd/wSpqmnaWwqYEgQXWLHCnkvQI5YjJR/ZpulbE Z+MUMPOOqiFYVpr19EBG0bfPZctZwlczT0BoLdvRJpR8WbFiZfW7yJ8jKge//oFM6EmA 2lCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=NXSY0vjV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m4si8151490edr.500.2020.08.15.15.09.39; Sat, 15 Aug 2020 15:10:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=NXSY0vjV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729820AbgHOWGp (ORCPT + 99 others); Sat, 15 Aug 2020 18:06:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728370AbgHOVus (ORCPT ); Sat, 15 Aug 2020 17:50:48 -0400 Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com [IPv6:2a00:1450:4864:20::644]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF194C03B3D7; Sat, 15 Aug 2020 02:13:41 -0700 (PDT) Received: by mail-ej1-x644.google.com with SMTP id o23so12397796ejr.1; Sat, 15 Aug 2020 02:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=mqUm0D+LR1fyNqgEpWLZcUrJ5fpnGERJD73F5yobxbo=; b=NXSY0vjVE5tPHf7IuLRoeAubB/ylXeS1/3XQ5D3uq+prksg4wr/wFryYS9yTbnP4di md8LZYgPigun2do3qz7miFA87HgFqeha4DH/nrgJKN4AMqw5+ZFiSPMktIap/pH51ROs Lf+qBonK2VWqkiID86N7ws1hIx9M/X8nFu8khVOTcQmH1XGaO2heo3a3pdXQvRfPUrPI LRFzwQH/I7fHgLt4hXEbBHiyUGrfwXPAQkMWzl2/uu8PJQbqhb0fqXgpBibI2wLIgLxq l0VRUKBV7N9Bp/Qv8e462/XXOHTUn6sjVI0jagAwFgNceU//9a1xtL5ZZpwezfq1HQsP eBLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=mqUm0D+LR1fyNqgEpWLZcUrJ5fpnGERJD73F5yobxbo=; b=pyDfon05IZFlBRLYZop3TmKHWwzWlLbjEvCRFhUhwO6BhJhB+J7urkNUH8RT+H6kKB V580o0wELpNPOVA1fKyDbtBOvY1tJntGewT7kPucEI3yIGjZvsaYaqHZerhqEeKPUV6R SP6I5XPBK5cKT4eF1DiM9Ubm4qJf2s4GysHBzi03mHRUBE7DP7RJJKIC0J0WcddPlPN9 JYaxZZSmh4XXz5fowAFvsIiQ5yzUl8lSK6QUXlPXPu9aZxGRnVbFHpoib4a2HETnjWEn RekonfjavKYoDMb5sLxERnTbZEFRUcWV80bTxiUY/GJh7DSOs4ufcyswA2WajZTnzwqL 5I8Q== X-Gm-Message-State: AOAM530R51w3PBb6Wds7Tha0qQ4LG/ynrLmabQ4zwWOfNrICIKWPxRlG Gg8wrbNfEcxs+JIe3o6x4No= X-Received: by 2002:a17:906:af0c:: with SMTP id lx12mr6308746ejb.228.1597482820529; Sat, 15 Aug 2020 02:13:40 -0700 (PDT) Received: from gmail.com (54033286.catv.pool.telekom.hu. [84.3.50.134]) by smtp.gmail.com with ESMTPSA id dr21sm9275800ejc.112.2020.08.15.02.13.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Aug 2020 02:13:39 -0700 (PDT) Date: Sat, 15 Aug 2020 11:13:36 +0200 From: Ingo Molnar To: Yazen Ghannam Cc: linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org, bp@suse.de, tony.luck@intel.com, x86@kernel.org, Smita.KoralahalliChannabasappa@amd.com Subject: Re: [PATCH 2/2] x86/MCE/AMD Support new memory interleaving schemes during address translation Message-ID: <20200815091336.GB2444151@gmail.com> References: <20200814191449.183998-1-Yazen.Ghannam@amd.com> <20200814191449.183998-3-Yazen.Ghannam@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200814191449.183998-3-Yazen.Ghannam@amd.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Yazen Ghannam wrote: > + /* Read D18F1x208 (System Fabric ID Mask 0). */ > + if (amd_df_indirect_read(nid, 1, 0x208, umc, &tmp)) > + goto out_err; > + > + /* Determine if system is a legacy Data Fabric type. */ > + legacy_df = !(tmp & 0xFF); 1) I see this pattern in a lot of places in the code, first the magic constant 0x208 is explained a comment, then it is *repeated* and used it in the code... How about introducing an obviously named enum for it instead, which would then be self-documenting, saving the comment and removing magic numbers: if (amd_df_indirect_read(nid, 1, AMD_REG_FAB_ID, umc, ®_fab_id)) goto out_err; (The symbolic name should be something better, I just guessed something quickly.) Please clean this up in a separate patch, not part of the already large patch that introduces a new feature. 2) 'tmp & 0xFF' is some sort of fabric version ID value, with a value of 0 denoting legacy (pre-Rome) systems, right? How about making that explicit: df_version = reg_fab_id & 0xFF; I'm pretty sure such a version ID might come handy later on, should there be quirks or new capabilities with the newer systems ... > ret_addr -= hi_addr_offset; > @@ -728,23 +740,31 @@ int umc_normaddr_to_sysaddr(u64 norm_addr, u16 nid, u8 umc, u64 *sys_addr) > } > > lgcy_mmio_hole_en = tmp & BIT(1); > - intlv_num_chan = (tmp >> 4) & 0xF; > - intlv_addr_sel = (tmp >> 8) & 0x7; > - dram_base_addr = (tmp & GENMASK_ULL(31, 12)) << 16; > > - /* {0, 1, 2, 3} map to address bits {8, 9, 10, 11} respectively */ > - if (intlv_addr_sel > 3) { > - pr_err("%s: Invalid interleave address select %d.\n", > - __func__, intlv_addr_sel); > - goto out_err; > + if (legacy_df) { > + intlv_num_chan = (tmp >> 4) & 0xF; > + intlv_addr_sel = (tmp >> 8) & 0x7; > + } else { > + intlv_num_chan = (tmp >> 2) & 0xF; > + intlv_num_dies = (tmp >> 6) & 0x3; > + intlv_num_sockets = (tmp >> 8) & 0x1; > + intlv_addr_sel = (tmp >> 9) & 0x7; > } > > + dram_base_addr = (tmp & GENMASK_ULL(31, 12)) << 16; > + > /* Read D18F0x114 (DramLimitAddress). */ > if (amd_df_indirect_read(nid, 0, 0x114 + (8 * base), umc, &tmp)) > goto out_err; > > - intlv_num_sockets = (tmp >> 8) & 0x1; > - intlv_num_dies = (tmp >> 10) & 0x3; > + if (legacy_df) { > + intlv_num_sockets = (tmp >> 8) & 0x1; > + intlv_num_dies = (tmp >> 10) & 0x3; > + dst_fabric_id = tmp & 0xFF; > + } else { > + dst_fabric_id = tmp & 0x3FF; > + } > + > dram_limit_addr = ((tmp & GENMASK_ULL(31, 12)) << 16) | GENMASK_ULL(27, 0); Could we please structure this code in a bit more readable fashion? 1) Such as not using the meaningless 'tmp' variable name to first read out DramOffset, then DramLimitAddress? How about naming them a bit more obviously, and retrieving them in a single step: if (amd_df_indirect_read(nid, 0, 0x1B4, umc, ®_dram_off)) goto out_err; /* Remove HiAddrOffset from normalized address, if enabled: */ if (reg_dram_off & BIT(0)) { u64 hi_addr_offset = (tmp & GENMASK_ULL(31, 20)) << 8; if (norm_addr >= hi_addr_offset) { ret_addr -= hi_addr_offset; base = 1; } } if (amd_df_indirect_read(nid, 0, 0x114 + (8 * base), umc, ®_dram_lim)) goto out_err; ('reg' stands for register value - but 'val' would work too.) Side note: why is the above code using BIT() and GENMASK_UUL() when all the other and new code is using fixed masks? Use one of these versions instead of a weird mix ... 2) Then all the fabric version dependent logic could be consolidated instead of being spread out: if (df_version) { intlv_num_chan = (reg_dram_off >> 2) & 0xF; intlv_num_dies = (reg_dram_off >> 6) & 0x3; intlv_num_sockets = (reg_dram_off >> 8) & 0x1; intlv_addr_sel = (reg_dram_off >> 9) & 0x7; dst_fabric_id = (reg_dram_lim >> 0) & 0x3FF; } else { intlv_num_chan = (reg_dram_off >> 4) & 0xF; intlv_num_dies = (reg_dram_lim >> 10) & 0x3; intlv_num_sockets = (reg_dram_lim >> 8) & 0x1; intlv_addr_sel = (reg_dram_off >> 8) & 0x7; dst_fabric_id = (reg_dram_lim >> 0) & 0xFF; } Also note a couple of more formatting & ordering edits I did to the code, to improve the structure. My copy & paste job is untested though. 3) Notably, note how the new code on current systems is the first branch - that's the most interesting code most of the time anyaway, legacy systems being legacy. BTW., please do any such suggested code flow and structure clean-up patches first in the series, then introduce the new logic, to make it easier to verify. Thanks, Ingo