Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp1060021rwi; Wed, 19 Oct 2022 06:19:38 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7FeODwq7jfGrL/eK975zE0YU21XIUiQZf63ARRxtIeD4eG39EbEZdJEN/ab+LdGuhWwGic X-Received: by 2002:a05:6a00:1ace:b0:565:f52a:d998 with SMTP id f14-20020a056a001ace00b00565f52ad998mr8546000pfv.25.1666185577652; Wed, 19 Oct 2022 06:19:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666185577; cv=none; d=google.com; s=arc-20160816; b=EnKnzYhPWu5XDAg0U7l+b5BJHGCc1V7rGeDV9lMeYhM9l7kw21yo/xzjSdt57FJfCT CVMtwMIroJPB7UIo1hIL2pkkw0oZg5D4fnzwjTXXSbWhXuCVoB8gGvzHYhG5aj+e19Mg hpQwxDHqV0Vn0Kbpo2ozgioUPGg+l8lKHQuJTtNC2i5L4QdAmX6b2Fso5byUcl/I1Tah X6T0Bvve8oSEZ9HULgRoc2+ALcFWvqUK1zhZKkx4JZOpZm9tXDNUpX+nGIEc0gwOYlwZ 8z6aGYrWK3J1Qq6GZjvRhKlUPo9IOOubQtMFpMFQbAzAy+tqIKLqcO4kgcsTxZLnWEA6 vq8A== 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:dkim-signature; bh=QMeiIZiyblteVRq78CiV17LjNnwkts3YE/C63wZ/Nwc=; b=Ba+EVgAb8dVa3bAl8X1a14F98z+edEQslRpnr2QgcxJvnMCZDO2XHWVxR7bsiObaxC uXl612OGxBwkLRI6Ph6KJQZX+2Zkd+k0fr6IVezHMQf6kZFjUTuBCd0kodMS9q+dP9SN aCAqWZQaQ6VxWewjnedOF2KYwQXSpnDf+RXdtA16VfQkzf38mkzYZIh7Gn1y9Y6uyElv DBJE4d+MEubmHXPcUf7S05/0g0ZxicoOtESuYW7jrLt0sq2tvS/1Dhc4zO+XpGW+H+0A xnev6W56X5t6hc2ZLFNbAFF/gtfTbe7dTrm4Hc+CKs7yeqqE+JEabtZxgRTS1jNSz+y+ pPJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@brainfault-org.20210112.gappssmtp.com header.s=20210112 header.b=BOfrgwQg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j7-20020a170902da8700b001768b832a41si21412872plx.584.2022.10.19.06.19.25; Wed, 19 Oct 2022 06:19:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@brainfault-org.20210112.gappssmtp.com header.s=20210112 header.b=BOfrgwQg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231694AbiJSMmP (ORCPT + 99 others); Wed, 19 Oct 2022 08:42:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232582AbiJSMmB (ORCPT ); Wed, 19 Oct 2022 08:42:01 -0400 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B37F632042 for ; Wed, 19 Oct 2022 05:24:41 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id 13so39426170ejn.3 for ; Wed, 19 Oct 2022 05:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brainfault-org.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QMeiIZiyblteVRq78CiV17LjNnwkts3YE/C63wZ/Nwc=; b=BOfrgwQgEzrrFhKlFXE5x9tOZKfxASj6ILDrcwagHhpNJzX2kSs2Pfwaq05XnINQrP l9Dcw6XLRGkIV/RuE9xQwi3EOMuw+8BlM+Ttw8VcjZ1tO542VMZUeok+gYu6K2Oxcoyv JCS7h9hBMXUcEQpLUiz14l5B1rJUeimFAXFYKlVtg6KB/j5ZC3t1NvKNhYliUgE/09kP FvO3ZTD6PyMJqSljuEY6tvCuYO8TVwCyijjZjXl1Zj1l3BP5xzgYzNvZ72LIeSl75qJE gAVd+M+YBGvhGKF3dsq+fGiSHDVzzhN+pJS4OGO8eaYTaC3lfevZaCl2XTNxkVAAcOI0 oi8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QMeiIZiyblteVRq78CiV17LjNnwkts3YE/C63wZ/Nwc=; b=TmxgkYbhKNwXElN70OJlSplqrrwwXL57eglCSfBkz0kiRlAa48gueun0MYJ7iUAe+f Ep+MvBXeWR1jmsRaK5GmO4pALoYEdEOwp5X8EFquYurF6YlqISRNFfxmmyaZj+tghJIx 6zkYijmNEqr+m19DONZbkizPJ0t70cPT5MJc+fZHPcJCC5ZTTXf1qqJCg/Aja9zdxjvA ZtkujCHqr4wKrocFdUzK640QYYLomJqo4GtMomsy3vqom/2kPjWY0wp5bdNzmHszalYR LhEMCQcSJbu6IBvXhUU8cUR7/Se2Z6MG1GgUMBog10vDbpyg/u69mB1CtRFEcDyRDskr zyGQ== X-Gm-Message-State: ACrzQf0x/aBXUMGn8T5r5CFuKKaz8r8DX328JIqH71S7ITq1vK+Dyq5L iVHpT1s7j+WPs9+4IC/5EkKxQr+anxWmP2VqXgm7Ng== X-Received: by 2002:a17:906:ee81:b0:77e:829a:76e9 with SMTP id wt1-20020a170906ee8100b0077e829a76e9mr6852093ejb.207.1666182176287; Wed, 19 Oct 2022 05:22:56 -0700 (PDT) MIME-Version: 1.0 References: <20221019121622.179024-1-apatel@ventanamicro.com> <20221019121622.179024-2-apatel@ventanamicro.com> In-Reply-To: <20221019121622.179024-2-apatel@ventanamicro.com> From: Anup Patel Date: Wed, 19 Oct 2022 17:52:42 +0530 Message-ID: Subject: Re: [PATCH v3 1/4] RISC-V: Fix compilation without RISCV_ISA_ZICBOM To: Palmer Dabbelt Cc: Paul Walmsley , Atish Patra , Heiko Stuebner , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Andrew Jones , kernel test robot , Anup Patel , Conor Dooley Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Palmer, On Wed, Oct 19, 2022 at 5:46 PM Anup Patel wrote: > > From: Andrew Jones > > riscv_cbom_block_size and riscv_init_cbom_blocksize() should always > be available and riscv_init_cbom_blocksize() should always be > invoked, even when compiling without RISCV_ISA_ZICBOM enabled. This > is because disabling RISCV_ISA_ZICBOM means "don't use zicbom > instructions in the kernel" not "pretend there isn't zicbom, even > when there is". When zicbom is available, whether the kernel enables > its use with RISCV_ISA_ZICBOM or not, KVM will offer it to guests. > Ensure we can build KVM and that the block size is initialized even > when compiling without RISCV_ISA_ZICBOM. > > Fixes: 8f7e001e0325 ("RISC-V: Clean up the Zicbom block size probing") > Reported-by: kernel test robot > Signed-off-by: Andrew Jones > Signed-off-by: Anup Patel > Reviewed-by: Conor Dooley Currently, the KVM RISC-V compilation is broken for toolchains not having Zicbom support. I plan to take this patch through the KVM RISC-V tree and I will be sending a PR by the end of this week. Let me know if you want this patch to go through the RISC-V tree. Regards, Anup > --- > arch/riscv/mm/cacheflush.c | 41 +++++++++++++++++++++++++++++++++ > arch/riscv/mm/dma-noncoherent.c | 41 --------------------------------- > 2 files changed, 41 insertions(+), 41 deletions(-) > > diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c > index 6cb7d96ad9c7..f318b2553612 100644 > --- a/arch/riscv/mm/cacheflush.c > +++ b/arch/riscv/mm/cacheflush.c > @@ -3,6 +3,8 @@ > * Copyright (C) 2017 SiFive > */ > > +#include > +#include > #include > > #ifdef CONFIG_SMP > @@ -86,3 +88,42 @@ void flush_icache_pte(pte_t pte) > flush_icache_all(); > } > #endif /* CONFIG_MMU */ > + > +unsigned int riscv_cbom_block_size; > +EXPORT_SYMBOL_GPL(riscv_cbom_block_size); > + > +#ifdef CONFIG_RISCV_ISA_ZICBOM > +void riscv_init_cbom_blocksize(void) > +{ > + struct device_node *node; > + unsigned long cbom_hartid; > + u32 val, probed_block_size; > + int ret; > + > + probed_block_size = 0; > + for_each_of_cpu_node(node) { > + unsigned long hartid; > + > + ret = riscv_of_processor_hartid(node, &hartid); > + if (ret) > + continue; > + > + /* set block-size for cbom extension if available */ > + ret = of_property_read_u32(node, "riscv,cbom-block-size", &val); > + if (ret) > + continue; > + > + if (!probed_block_size) { > + probed_block_size = val; > + cbom_hartid = hartid; > + } else { > + if (probed_block_size != val) > + pr_warn("cbom-block-size mismatched between harts %lu and %lu\n", > + cbom_hartid, hartid); > + } > + } > + > + if (probed_block_size) > + riscv_cbom_block_size = probed_block_size; > +} > +#endif > diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c > index b0add983530a..d919efab6eba 100644 > --- a/arch/riscv/mm/dma-noncoherent.c > +++ b/arch/riscv/mm/dma-noncoherent.c > @@ -8,13 +8,8 @@ > #include > #include > #include > -#include > -#include > #include > > -unsigned int riscv_cbom_block_size; > -EXPORT_SYMBOL_GPL(riscv_cbom_block_size); > - > static bool noncoherent_supported; > > void arch_sync_dma_for_device(phys_addr_t paddr, size_t size, > @@ -77,42 +72,6 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size, > dev->dma_coherent = coherent; > } > > -#ifdef CONFIG_RISCV_ISA_ZICBOM > -void riscv_init_cbom_blocksize(void) > -{ > - struct device_node *node; > - unsigned long cbom_hartid; > - u32 val, probed_block_size; > - int ret; > - > - probed_block_size = 0; > - for_each_of_cpu_node(node) { > - unsigned long hartid; > - > - ret = riscv_of_processor_hartid(node, &hartid); > - if (ret) > - continue; > - > - /* set block-size for cbom extension if available */ > - ret = of_property_read_u32(node, "riscv,cbom-block-size", &val); > - if (ret) > - continue; > - > - if (!probed_block_size) { > - probed_block_size = val; > - cbom_hartid = hartid; > - } else { > - if (probed_block_size != val) > - pr_warn("cbom-block-size mismatched between harts %lu and %lu\n", > - cbom_hartid, hartid); > - } > - } > - > - if (probed_block_size) > - riscv_cbom_block_size = probed_block_size; > -} > -#endif > - > void riscv_noncoherent_supported(void) > { > WARN(!riscv_cbom_block_size, > -- > 2.34.1 >