From: Andrew Jones <ajones@ventanamicro.com>
To: Conor Dooley <conor.dooley@microchip.com>
Cc: Vernon Yang <vernon2gm@gmail.com>,
lkp@intel.com, anup@brainfault.org, atishp@rivosinc.com,
kbuild-all@lists.01.org, linux-mm@kvack.org,
linux-riscv@lists.infradead.org
Subject: Re: [PATCH] RISC-V: KVM: fixup undefined reference to riscv_cbom_block_size
Date: Mon, 10 Oct 2022 08:59:49 +0200 [thread overview]
Message-ID: <20221010065949.is3kf54ctt2kdmjd@kamzik> (raw)
In-Reply-To: <Y0O+vEC3/fnUKgxw@wendy>
On Mon, Oct 10, 2022 at 07:42:04AM +0100, Conor Dooley wrote:
> On Mon, Oct 10, 2022 at 09:33:29AM +0800, Vernon Yang wrote:
> > When some RISC-V compilers do not support the Zicbom extension,
> > the build system auto disable the CONFIG_RISCV_ISA_ZICBOM, so the
> > source code of the relevant function is not compiled, resulting
> > in the definition of the riscv_cbom_block_size variable cannot
> > be found
>
> Hmm, my understanding was that riscv_cbom_block_size was not supposed to
> depend on CONFIG_RISCV_ISA_ZICBOM because the thead is able to use it
> even if the toolchain does not support it.
>
> The code in cacheflush.h looks like:
> extern unsigned int riscv_cbom_block_size;
> #ifdef CONFIG_RISCV_ISA_ZICBOM
> void riscv_init_cbom_blocksize(void);
> #else
> static inline void riscv_init_cbom_blocksize(void) { }
> #endif
>
> #ifdef CONFIG_RISCV_DMA_NONCOHERENT
> void riscv_noncoherent_supported(void);
> #endif
>
> It's early and I only had a quick look but I think that this is not
> defined because RISCV_DMA_NONCOHERENT is not defined, not because of
> RISCV_ISA_ZICBOM.
thead is able to use riscv_cbom_block_size because it does its own
initialization of it and selects RISCV_DMA_NONCOHERENT to get access
to it. KVM depends on the initializer in dma-noncoherent.c, which is
guarded by RISCV_ISA_ZICBOM and does not select RISCV_DMA_NONCOHERENT,
but RISCV_ISA_ZICBOM does. I think guarding use of riscv_cbom_block_size
with RISCV_ISA_ZICBOM in KVM makes sense.
> I'm not the KVM maintainer, but I dislike #ifdefery
> in c files, so it'd be nice I think to sort this out in the header and
> not have to worry about guarding the variable.
I also dislike #ifdefery, but unless we move riscv_cbom_block_size to
an unconditionally built file like cacheflush.c (as Anup once did), then
we don't have much choice.
Thanks,
drew
next prev parent reply other threads:[~2022-10-10 6:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-09 4:12 [linux-next:master 11281/12775] vcpu.c:undefined reference to `riscv_cbom_block_size' kernel test robot
2022-10-10 1:33 ` [PATCH] RISC-V: KVM: fixup undefined reference to riscv_cbom_block_size Vernon Yang
2022-10-10 6:42 ` Conor Dooley
2022-10-10 6:59 ` Andrew Jones [this message]
2022-10-10 7:05 ` Conor Dooley
2022-10-10 6:44 ` Andrew Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221010065949.is3kf54ctt2kdmjd@kamzik \
--to=ajones@ventanamicro.com \
--cc=anup@brainfault.org \
--cc=atishp@rivosinc.com \
--cc=conor.dooley@microchip.com \
--cc=kbuild-all@lists.01.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=lkp@intel.com \
--cc=vernon2gm@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox