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;
MIME-Version: 1.0
References: <20221202075854.2253116-1-maobibo@loongson.cn> <07e0d775-6bb7-051b-9ec9-71153efbdf21@xen0n.name>
 <c5e1b113-f457-2cc7-808b-b13f83adbb2b@loongson.cn> <c00462a5-c5c0-a749-15aa-c0efaf232e71@xen0n.name>
In-Reply-To: <c00462a5-c5c0-a749-15aa-c0efaf232e71@xen0n.name>
From:   Huacai Chen <chenhuacai@kernel.org>
Date:   Thu, 8 Dec 2022 21:03:21 +0800
Message-ID: <CAAhV-H62s_VL2Mv5_1CFkT7+JVvJd6Nmv18=aw9V_YU+AmsJGw@mail.gmail.com>
Subject: Re: [PATCH] LoongArch: export symbol with function smp_send_reschedule
To:     WANG Xuerui <kernel@xen0n.name>
Cc:     maobibo <maobibo@loongson.cn>, loongarch@lists.linux.dev,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Applied, thanks.

Huacai

On Fri, Dec 2, 2022 at 5:41 PM WANG Xuerui <kernel@xen0n.name> wrote:
>
> On 2022/12/2 17:03, maobibo wrote:
> >>> diff --git a/arch/loongarch/kernel/smp.c b/arch/loongarch/kernel/smp.=
c
> >>> index 6ed72f7ff278..51dd3c3f06cb 100644
> >>> --- a/arch/loongarch/kernel/smp.c
> >>> +++ b/arch/loongarch/kernel/smp.c
> >>> @@ -141,6 +141,17 @@ void loongson_send_ipi_single(int cpu, unsigned =
int action)
> >>>        ipi_write_action(cpu_logical_map(cpu), (u32)action);
> >>>    }
> >>>    +/*
> >>> + * This function sends a 'reschedule' IPI to another CPU.
> >>> + * it goes straight through and wastes no time serializing
> >>> + * anything. Worst case is that we lose a reschedule ...
> >>> + */
> >>> +void smp_send_reschedule(int cpu)
> >>> +{
> >>> +    loongson_send_ipi_single(cpu, SMP_RESCHEDULE);
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(smp_send_reschedule);
> >>> +
> >>
> >> While the change is in itself okay (one less case of mips legacy, gett=
ing in line with ia64, powerpc and riscv that all EXPORT_SYMBOL_GPL this), =
I'd suggest you batch this patch with the subsequent changes you plan to en=
able with this one, so reviewers would have more context and hopefully avoi=
d churn. (I, by my familiarity with Loongson and LoongArch development, kno=
w you're probably aiming to use this with KVM, but others probably don't kn=
ow, and again it's always better to have more context.)
> >>
> >
> > yes, kvm module depends on function smp_send_reschedule, only that it i=
s not mature now. And this function is standard API, not arch specified API=
, it is normal for modules to use it :)
>
> Hmm, maybe you could post some kind of "sneak peek" code for early
> reviews on broader things like overall approach and architecture?
> Frankly speaking, experience suggests that code from Loongson usually
> needs much refactoring to meet mainline standards, and posting your
> design and some initial implementation could save you and the community
> a *huge* amount of time and hassle.
>
> And I'm not arguing this patch shouldn't get included, it's the
> opposite, but I don't see any difference in applying it now or later
> when the whole LoongArch KVM support gets mainlined, so maybe it's
> better to wait so we don't cause any churn if the change turns out
> unnecessary. For example, in my grepping I found that x86 doesn't have
> smp_send_reschedule exported, yet its KVM port has no problem using it;
> and that the s390 and riscv KVM ports don't invoke smp_send_reschedule
> at all. So it's entirely possible that LoongArch won't need this change
> for KVM after all, and I'm suggesting to save everyone some time.
>
> --
> WANG "xen0n" Xuerui
>
> Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
>
>