Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp6102412pxb; Thu, 27 Jan 2022 06:36:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJx4QfbAyjx/+oubUilpbDDn+hrPNWxHbGPblSB5u99gyHwDGCTYn2KOzfOasvUDN6DoY1m1 X-Received: by 2002:a17:90b:33c6:: with SMTP id lk6mr4459638pjb.213.1643294206891; Thu, 27 Jan 2022 06:36:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643294206; cv=none; d=google.com; s=arc-20160816; b=oN/vRFThxi+tCmfpH2VSV0T/2WGJ5LNmbZnh8I8hRLE5r/Jg1icscPmAvp9Smp7MYs sWhYl2tXi5wWvcHvW3L9kV6zPLm8UsPlO9GxB5RuzhA/DQIigGVXXtX+ic+/7gFtYriV wjq2k7cMqmxYexJ1o0QHMm7gU3IHdKeR966CmzB20Rywoyrw2FMLn8UDlrZYpmHHnM0O 0AePQPXPD5IDdPFwnfz8uHG+cpJrXc2zcY1vsHQfbbcu/7K7OzfO2rlwZaaVe9HPo2Qq 1yZw6TUUv0NZve8VcAf99+8L3MmZcvL+sVVeHv1F2Va3Zc1Faq9Qz8DBxulyIOY1HrBF kuEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=tiYQ03BGYl3eFh9sLWDt0ZrzOmKrMYMSVnNiMqCKOig=; b=yb5nO1goXwzGy01S8ItjLbHoeHDRYfAdKgm0E3pPKLL/iaaIQVDB6/cFi8Pb9REvWc 4YsCXimDe53pG27akCv+3HQbrQXecPenACEhKK0cnuwUNf/Z0zFE4G7xZg8t1+w/CmSy jpTTJ8fwupnXriWTZPW36+PJf6yyVAOVTSqNaFD6M9OOILKJx7D5qjrufM07VaM4vEiN NL7Nu/469ubR+usHuWnLiXLGp1y1fYRC3HVa/GgV73LgYz2dkUXMSflBOZmHLkK0ku8I NpoymVL8YJAnY5aw1l73rRgv2+Xy4xIGZnxU+UlLfzDTQQ9bG3jyKuLfS0X8D9nQSeKV Zu9A== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y9si5240725pjp.56.2022.01.27.06.36.34; Thu, 27 Jan 2022 06:36:46 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237913AbiA0ItH (ORCPT + 99 others); Thu, 27 Jan 2022 03:49:07 -0500 Received: from mail-vk1-f175.google.com ([209.85.221.175]:46074 "EHLO mail-vk1-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231455AbiA0ItG (ORCPT ); Thu, 27 Jan 2022 03:49:06 -0500 Received: by mail-vk1-f175.google.com with SMTP id l14so141097vko.12; Thu, 27 Jan 2022 00:49:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tiYQ03BGYl3eFh9sLWDt0ZrzOmKrMYMSVnNiMqCKOig=; b=fZKhogag9IJbYfJdAGv5duwrEPS4E62orY5keAKMpaigo1xnm6h8vOVlu7kR84LN9x mz6mYCEeZ8qCHsVORSSqwQba+r5n2R56m2KA3eQR7JB3snuzz3resOHocS2IoiyiD+CF SXMoTWTJzPSB04oy4zmwLbC4EddGm4CyXYAmammFlGD0XWvtH7SwxydkDbh0MXwV4N/4 7FG2nRzRlP7BoBYUCYtTl/G5U2F8IEQ5YqnsYb2/hcuf8nXk6RolFX3wgZkQ5YzmI0u6 9wxcDMn3AbmrOn1+Qz1Ni5P2eYy4z4Dqlvt3eMwxVW3BtkZihcY6BSREm/J4xQfZWlay Fwyw== X-Gm-Message-State: AOAM5300W/WX5N1PiohGf2VA21CcO/6vZ72tA+GOEld2vKNerwoePo4Q q+393X9wHSwPwioERGpOTO0BE4YYyhI8HA== X-Received: by 2002:a05:6122:551:: with SMTP id y17mr819651vko.37.1643273345862; Thu, 27 Jan 2022 00:49:05 -0800 (PST) Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com. [209.85.221.169]) by smtp.gmail.com with ESMTPSA id n18sm456039vkq.7.2022.01.27.00.49.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Jan 2022 00:49:05 -0800 (PST) Received: by mail-vk1-f169.google.com with SMTP id l14so141061vko.12; Thu, 27 Jan 2022 00:49:04 -0800 (PST) X-Received: by 2002:a1f:5d84:: with SMTP id r126mr1015757vkb.33.1643273344756; Thu, 27 Jan 2022 00:49:04 -0800 (PST) MIME-Version: 1.0 References: <20220120090918.2646626-1-atishp@rivosinc.com> <20220120090918.2646626-7-atishp@rivosinc.com> <1AA3005C-E9C8-4E4B-900D-DD48B37CEA41@jrtc27.com> In-Reply-To: From: Geert Uytterhoeven Date: Thu, 27 Jan 2022 09:48:53 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 6/6] RISC-V: Do not use cpumask data structure for hartid bitmap To: Atish Patra Cc: Jessica Clarke , Atish Patra , Linux Kernel Mailing List , Anup Patel , Albert Ou , Damien Le Moal , devicetree , Jisheng Zhang , Krzysztof Kozlowski , linux-riscv , Palmer Dabbelt , Paul Walmsley , Rob Herring Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 27, 2022 at 9:48 AM Geert Uytterhoeven wrote: > On Thu, Jan 27, 2022 at 2:02 AM Atish Patra wrote: > > On Wed, Jan 26, 2022 at 1:10 AM Geert Uytterhoeven wrote: > > > On Wed, Jan 26, 2022 at 9:28 AM Geert Uytterhoeven wrote: > > > > On Wed, Jan 26, 2022 at 3:21 AM Atish Patra wrote: > > > > > On Tue, Jan 25, 2022 at 2:26 PM Jessica Clarke wrote: > > > > > > On 20 Jan 2022, at 09:09, Atish Patra wrote: > > > > > > > Currently, SBI APIs accept a hartmask that is generated from struct > > > > > > > cpumask. Cpumask data structure can hold upto NR_CPUs value. Thus, it > > > > > > > is not the correct data structure for hartids as it can be higher > > > > > > > than NR_CPUs for platforms with sparse or discontguous hartids. > > > > > > > > > > > > > > Remove all association between hartid mask and struct cpumask. > > > > > > > > > > > > > > Reviewed-by: Anup Patel (For Linux RISC-V changes) > > > > > > > Acked-by: Anup Patel (For KVM RISC-V changes) > > > > > > > Signed-off-by: Atish Patra > > > > > > > > > I am yet to reproduce it on my end. > > > > > @Geert Uytterhoeven: can you please try the below diff on your end. > > > > > > > > Unfortunately it doesn't fix the issue for me. > > > > > > > > /me debugging... > > > > > > Found it: after this commit, the SBI_EXT_RFENCE_REMOTE_FENCE_I and > > > SBI_EXT_RFENCE_REMOTE_SFENCE_VMA ecalls are now called with > > > hmask = 0x8000000000000001 and hbase = 1 instead of hmask = 3 and > > > hbase = 0. > > > > > > cpuid 1 maps to hartid 0 > > > cpuid 0 maps to hartid 1 > > > > > > __sbi_rfence_v02:364: cpuid 1 hartid 0 > > > __sbi_rfence_v02:377: hartid 0 hbase 1 > > > hmask |= 1UL << (hartid - hbase); > > > > > > oops > > > > > > __sbi_rfence_v02_call:303: SBI_EXT_RFENCE_REMOTE_FENCE_I hmask > > > 8000000000000001 hbase 1 > > > > > > > Ahh yes. hmask will be incorrect if the bootcpu(cpu 0) is a higher > > hartid and it is trying to do a remote tlb flush/IPI > > to lower the hartid. We should generate the hartid array before the loop. > > > > Can you try this diff ? It seems to work for me during multiple boot > > cycle on the unleashed. > > > > You can find the patch here as well > > https://github.com/atishp04/linux/commits/v5.17-rc1 > > Thanks, that fixes the issue for me. Tested-by: Geert Uytterhoeven Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds