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;
Date:   Sat, 27 May 2023 14:22:02 +0100
Message-ID: <86leh9di4l.wl-maz@kernel.org>
From:   Marc Zyngier <maz@kernel.org>
To:     wangwudi <wangwudi@hisilicon.com>
Cc:     <linux-kernel@vger.kernel.org>
Subject: Re: [Question about gic vmovp cmd] Consider adding VINVALL after VMOVP
In-Reply-To: <ec4cba70-ba6f-2de6-29e8-945b0f52ed88@hisilicon.com>
References: <ba387464-59d5-0639-1d05-84bb7e764231@hisilicon.com>
        <87v8gfo9rg.wl-maz@kernel.org>
        <7f07c54fb0a4448fbccce0f97cb5e512@hisilicon.com>
        <ec4cba70-ba6f-2de6-29e8-945b0f52ed88@hisilicon.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
 FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2
 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sat, 27 May 2023 10:51:50 +0100,
wangwudi <wangwudi@hisilicon.com> wrote:
>=20
>=20
>=20
> =E5=9C=A8 2023/5/27 16:56, wangwudi =E5=86=99=E9=81=93:
> >=20
> >=20
> > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> > =E5=8F=91=E4=BB=B6=E4=BA=BA: Marc Zyngier [mailto:maz@kernel.org]=20
> > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2023=E5=B9=B45=E6=9C=8826=E6=97=
=A5 15:03
> > =E6=94=B6=E4=BB=B6=E4=BA=BA: wangwudi <wangwudi@hisilicon.com>
> > =E6=8A=84=E9=80=81: linux-kernel@vger.kernel.org
> > =E4=B8=BB=E9=A2=98: Re: [Question about gic vmovp cmd] Consider adding =
VINVALL after VMOVP
> >=20
> > On Fri, 26 May 2023 07:04:34 +0100,
> > wangwudi <wangwudi@hisilicon.com> wrote:
> >>
> >> Hi Marc,
> >>
> >> During vpe migration, VMOVP needs to be executed.
> >> If the vpe is migrated for the first time, especially before it is=20
> >> scheduled for the first time, there may be some unusual hanppens over =

> >> kexec.
> >=20
> > What may happen?
>=20
> Actually, I'm not sure.

Then what is that all for?

>=20
> >=20
> >> We might consider adding a VINVALL cmd after VMOVP to increase=20
> >> robustness.
> >=20
> > What are you trying to guarantee by adding this? From a
> > performance perspective, this is terrible as you're forcing the
> > ITS to drop its caches and reload everything, making the interrupt
> > latency far worse than what it should be on each and every vcpu
> > migration.
>=20
> Agree, this reduces performance.
>=20
> >=20
> > We already issue a VINVALL when a VPE is mapped. Why would you
> > need anything else?
> >=20
>=20
> It is just for robustness, like the VINALL when a VPE is mapped.

The VINVALL at the point a VPE is mapped serves a purpose: to
invalidate the caches from a previous instance of a VPE with the same
VPEID. It's not for "robustness" but for *correctness*.

>=20
> >>
> >> @@ -1327,6 +1327,7 @@ static void its_send_vmovp(struct its_vpe *vpe)
> >>
> >>                 desc.its_vmovp_cmd.col =3D &its->collections[col_id];
> >>                 its_send_single_vcommand(its, its_build_vmovp_cmd,=20
> >> &desc);
> >> +               its_send_vinvall(its, vpe);
> >>         }
> >>
> >> Do you think it's all right?
> >=20
> > I think this is pretty bad. If your HW requires this, then we can
> > add it as a workaround for your particular platform, but in
> > general, this is not needed.
>=20
> Got it, you are right :-).

May I suggest that in the future, you post patches that actually serve
a real purpose and avoid wasting people's time? Your company employs a
bunch of good people, some of which are pretty knowledgeable when it
comes to the GIC. Please consult with them before posting such thing.

Thanks,

	M.

--=20
Without deviation from the norm, progress is not possible.