Received: by 10.223.185.116 with SMTP id b49csp6474526wrg; Thu, 8 Mar 2018 08:02:34 -0800 (PST) X-Google-Smtp-Source: AG47ELs58uFXv9+KtotB1nuqk6SoWpo2yMuG7rY3+p1cVX1h9532Z6qyazWFPGoT0iNw5jvl0YGq X-Received: by 10.98.155.93 with SMTP id r90mr26962591pfd.132.1520524954164; Thu, 08 Mar 2018 08:02:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520524954; cv=none; d=google.com; s=arc-20160816; b=Wmv+Nau3UDu6unad+uuyD6pOB+cmrYoEBuJ025szMHRG5yYWpiXTITR0Rj2jom81Ce U93zTfrrKmqSEuxN36kpyDlWAgzjtZgd5VdK+InVyBp/B8/c6qE66EWeruD6WKJLnS5i 4F/5tAagbJ2GbEfzY/13PJxDdSCQ0VHf87HufR3bSaa/7pxnEKnYUDsUOtXzraYBe9Pw QLe3JIxnghdWE1Q89truocijP6jofuXJbGOs/b2M7fTaL3hmKLT0FKB+UV7wy91BZnvO EZkRht8f0b3bnAUqUIVGju/c8lrATSDHRRtukoTmHq96rt8He3hYR9w6u6U4XTqkoyqS XbSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=zI6PkDVz2dTOAz5wgCxUktpEbijfb6zZ0lqgRyad0aU=; b=Jvtd+me5fuxagTyZ/X6p40s+LdCs9xHdliVRuDIcx6ONOEXxxskdPD4yGt6MRHiHHb I5HGq7rzSyy1Ie23gAgL0leR1mrAJ1DnDV3C8iDFpXW+vbKuGzUmkf3E7Mk0WyPDj9Xy 4HyKemsx5uUb/oyJyTkuRlWjaIZZONgfLdxhBS28+QT0lSMQZ0hh1R9YamZRHYvkQkqm RkmTB6PJvW8CLkP1Rj1oikPFJKgu3UW5b2Q/r66UM8oFBt3cFu4Wap/FMqMW0vGKORZo 04LxX42wk8NgJ/5ErwMBxpTRAEvmn7uUStcyTItE6PzzCZ3r54FgF6WaW5L+M7leFgvA rGnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=g+EY78UC; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m17si15686820pfh.319.2018.03.08.08.02.17; Thu, 08 Mar 2018 08:02:34 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=g+EY78UC; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934440AbeCHP7c (ORCPT + 99 others); Thu, 8 Mar 2018 10:59:32 -0500 Received: from mail-io0-f173.google.com ([209.85.223.173]:39680 "EHLO mail-io0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754898AbeCHP7a (ORCPT ); Thu, 8 Mar 2018 10:59:30 -0500 Received: by mail-io0-f173.google.com with SMTP id b34so170615ioj.6 for ; Thu, 08 Mar 2018 07:59:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zI6PkDVz2dTOAz5wgCxUktpEbijfb6zZ0lqgRyad0aU=; b=g+EY78UCy7GFeSFpCx7OeoRv2ia1HTGC+3jO/Cw1k5XPkcg60DqC8IWzCgW7cNII7B wmfqkY/NVz0hX9T/sKV+HTJQrjm6Rtl5xb/cKSMWvCQMIfb90cwG6N/7bSQJQnXEMXWk Om1QxSRxXg+LloQFpWX6vgzEIt/pWGsdudPDw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zI6PkDVz2dTOAz5wgCxUktpEbijfb6zZ0lqgRyad0aU=; b=FKY8YdiTZf8fiqbBvuwdH5exBt9CTWBoI0ovp+z59JnLTrTKcWB1bLsQud8K1OhQnw miKC375t6aqgeUReBefUyN2kq2nKS1xquimFJTzrbaaaw1WPoEW9AZlAiX5dvd8s393M ngqLlIEmnjVaWMXKL5xh9W56JB14nIzuCBVw485/N42TFlOFrszn8w/LOF4Olt/lqhoz ewVuKtoHBr5/GSa5AzgmvfQWFM6WU49lCL768m/PjfNSPpCJ0B9eLJMOnhJtyKuhYeUd 3i3s6W0ev669M67cy584NSeEdAfwUc24MZf2MEw+vB2G2n0miaH6NUxtlGKrdtLGwNjF Y+vA== X-Gm-Message-State: AElRT7Gy0Hf5jznpy8tD3yndoLArS5T/YLxDXSPNV2L3VL1d+y/kC5YI IOuISNxX/iM2ZEpswIkA+U9LkjPorq3Gg5hCOC2Oow== X-Received: by 10.107.151.74 with SMTP id z71mr29641310iod.277.1520524769578; Thu, 08 Mar 2018 07:59:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.138.209 with HTTP; Thu, 8 Mar 2018 07:59:29 -0800 (PST) In-Reply-To: <1890b2e2-375e-f44f-c224-8cfa23a0add3@arm.com> References: <20180228220619.6992-1-jeremy.linton@arm.com> <8b5bfd7e-57ea-bb34-85f8-69007a3847e6@arm.com> <1890b2e2-375e-f44f-c224-8cfa23a0add3@arm.com> From: Ard Biesheuvel Date: Thu, 8 Mar 2018 15:59:29 +0000 Message-ID: Subject: Re: [PATCH v7 00/13] Support PPTT for ARM64 To: Jeremy Linton Cc: Sudeep Holla , linux-acpi@vger.kernel.org, Mark Rutland , vkilari@codeaurora.org, Lorenzo Pieralisi , austinwc@codeaurora.org, tnowicki@caviumnetworks.com, Greg Kroah-Hartman , "Rafael J. Wysocki" , dietmar.eggemann@arm.com, Will Deacon , Linux Kernel Mailing List , morten.rasmussen@arm.com, Al Stone , palmer@sifive.com, Hanjun Guo , Catalin Marinas , linux-riscv@lists.infradead.org, John Garry , wangxiongfeng2@huawei.com, linux-arm-kernel , Len Brown Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 27 February 2018 at 18:49, Jeremy Linton wrote: > On 03/01/2018 06:06 AM, Sudeep Holla wrote: >> >> Hi Jeremy, >> >> On 28/02/18 22:06, Jeremy Linton wrote: >>> >>> ACPI 6.2 adds the Processor Properties Topology Table (PPTT), which is >>> used to describe the processor and cache topology. Ideally it is >>> used to extend/override information provided by the hardware, but >>> right now ARM64 is entirely dependent on firmware provided tables. >>> >>> This patch parses the table for the cache topology and CPU topology. >>> When we enable ACPI/PPTT for arm64 we map the physical_id to the >>> PPTT node flagged as the physical package by the firmware. >>> This results in topologies that match what the remainder of the >>> system expects. To avoid inverted scheduler domains we then >>> set the MC domain equal to the largest cache within the socket >>> below the NUMA domain. >>> >> I remember reviewing and acknowledging most of the cacheinfo stuff with >> couple of minor suggestions for v6. I don't see any Acked-by tags in >> this series and don't know if I need to review/ack any more cacheinfo >> related patches. > > > Hi, > > Yes, I didn't put them in because I changed the functionality in 2/13 and > there is a bug fix in 5/13. I thought you might want to do a quick diff of > the git v6->v7 tree. > > Although given that most of the changes were in response to your comments in > v6 I probably should have just put the tags in. > I get sane output from lstopo when applying these patches and booting my Socionext SynQuacer in ACPI mode: $ lstopo-no-graphics Machine (31GB) Package L#0 + L3 L#0 (4096KB) L2 L#0 (256KB) L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0) L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#1) L2 L#1 (256KB) L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2 + PU L#2 (P#2) L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3 + PU L#3 (P#3) L2 L#2 (256KB) L1d L#4 (32KB) + L1i L#4 (32KB) + Core L#4 + PU L#4 (P#4) L1d L#5 (32KB) + L1i L#5 (32KB) + Core L#5 + PU L#5 (P#5) L2 L#3 (256KB) L1d L#6 (32KB) + L1i L#6 (32KB) + Core L#6 + PU L#6 (P#6) L1d L#7 (32KB) + L1i L#7 (32KB) + Core L#7 + PU L#7 (P#7) L2 L#4 (256KB) L1d L#8 (32KB) + L1i L#8 (32KB) + Core L#8 + PU L#8 (P#8) L1d L#9 (32KB) + L1i L#9 (32KB) + Core L#9 + PU L#9 (P#9) L2 L#5 (256KB) L1d L#10 (32KB) + L1i L#10 (32KB) + Core L#10 + PU L#10 (P#10) L1d L#11 (32KB) + L1i L#11 (32KB) + Core L#11 + PU L#11 (P#11) L2 L#6 (256KB) L1d L#12 (32KB) + L1i L#12 (32KB) + Core L#12 + PU L#12 (P#12) L1d L#13 (32KB) + L1i L#13 (32KB) + Core L#13 + PU L#13 (P#13) L2 L#7 (256KB) L1d L#14 (32KB) + L1i L#14 (32KB) + Core L#14 + PU L#14 (P#14) L1d L#15 (32KB) + L1i L#15 (32KB) + Core L#15 + PU L#15 (P#15) L2 L#8 (256KB) L1d L#16 (32KB) + L1i L#16 (32KB) + Core L#16 + PU L#16 (P#16) L1d L#17 (32KB) + L1i L#17 (32KB) + Core L#17 + PU L#17 (P#17) L2 L#9 (256KB) L1d L#18 (32KB) + L1i L#18 (32KB) + Core L#18 + PU L#18 (P#18) L1d L#19 (32KB) + L1i L#19 (32KB) + Core L#19 + PU L#19 (P#19) L2 L#10 (256KB) L1d L#20 (32KB) + L1i L#20 (32KB) + Core L#20 + PU L#20 (P#20) L1d L#21 (32KB) + L1i L#21 (32KB) + Core L#21 + PU L#21 (P#21) L2 L#11 (256KB) L1d L#22 (32KB) + L1i L#22 (32KB) + Core L#22 + PU L#22 (P#22) L1d L#23 (32KB) + L1i L#23 (32KB) + Core L#23 + PU L#23 (P#23) HostBridge L#0 PCIBridge PCIBridge PCI 1b21:0612 Block(Disk) L#0 "sda" HostBridge L#3 PCI 10de:128b GPU L#1 "renderD128" GPU L#2 "card0" GPU L#3 "controlD64" So Tested-by: Ard Biesheuvel *However*, while hacking on the firmware that exposes the table, I noticed that a malformed structure (incorrect size) can get the parser in an infinite loop, hanging the boot after [ 8.244281] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 8.251780] Serial: AMBA driver [ 8.255042] msm_serial: driver initialized [ 8.259752] ACPI PPTT: Cache Setup ACPI cpu 0 [ 8.264121] ACPI PPTT: Looking for data cache [ 8.268484] ACPI PPTT: Looking for CPU 0's level 1 cache type 0 so I guess the parsing code could be made a bit more robust?