From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55724C77B7C for ; Fri, 26 May 2023 07:02:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242346AbjEZHCw (ORCPT ); Fri, 26 May 2023 03:02:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48090 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230097AbjEZHCu (ORCPT ); Fri, 26 May 2023 03:02:50 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2EEF39E for ; Fri, 26 May 2023 00:02:49 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B54CF6435F for ; Fri, 26 May 2023 07:02:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18FC4C433D2; Fri, 26 May 2023 07:02:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685084568; bh=+Wap10aK5QlMsWScfGDsv6/vAV3gJt/86bxaGdaCTS8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Tsfb41dFNemTtBgMHm45V7q+CMpXsCxxHu6Mck4e7bu2hMN+QCv7DqinNfamVqjDq 7HeVBMJhs5cGRdSwQrcW34uvd7R5QUahxXGT17D8QcEfzk9QTROI4KqEznIExbp7Y5 Qvtn0OvAWbBQL42+NtS4QHiwlOugkbhxxq608rGPvxcuYrzTJznYlEBxI+k9pGhncp rO8semd+Cni7RG3+kDIZORhPNKg4ut0ePLRuRAERQ1Irh2ymxB9S9svmV+2yE9neWn dVu3FgO8pB8L/r1DqB05Ut/hJr9rmtGtWz9S+CDJYMlV6YmrmtW2oCLQA5q3FW3phs dwzwVEv9ULolQ== Received: from ip-185-104-136-29.ptr.icomera.net ([185.104.136.29] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1q2RTJ-000Uvc-KK; Fri, 26 May 2023 08:02:45 +0100 Date: Fri, 26 May 2023 08:02:43 +0100 Message-ID: <87v8gfo9rg.wl-maz@kernel.org> From: Marc Zyngier To: wangwudi Cc: Subject: Re: [Question about gic vmovp cmd] Consider adding VINVALL after VMOVP In-Reply-To: References: 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 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.104.136.29 X-SA-Exim-Rcpt-To: wangwudi@hisilicon.com, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 26 May 2023 07:04:34 +0100, wangwudi wrote: > > Hi Marc, > > During vpe migration, VMOVP needs to be executed. > If the vpe is migrated for the first time, especially before it is > scheduled for the first time, there may be some unusual hanppens > over kexec. What may happen? > We might consider adding a VINVALL cmd after VMOVP to > increase robustness. 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. We already issue a VINVALL when a VPE is mapped. Why would you need anything else? > > @@ -1327,6 +1327,7 @@ static void its_send_vmovp(struct its_vpe *vpe) > > desc.its_vmovp_cmd.col = &its->collections[col_id]; > its_send_single_vcommand(its, its_build_vmovp_cmd, &desc); > + its_send_vinvall(its, vpe); > } > > Do you think it's all right? 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. Thanks, M. -- Without deviation from the norm, progress is not possible.