Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp2036751rwd; Fri, 26 May 2023 00:15:41 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6YwobuKOkTqEcjhrXBHy3Hk1e2taA4EJ+6xrPvUlxzZo48lYo7qwXiqrOzNVH6kY4efCin X-Received: by 2002:a05:6a20:1613:b0:102:a593:a161 with SMTP id l19-20020a056a20161300b00102a593a161mr1152838pzj.57.1685085341679; Fri, 26 May 2023 00:15:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685085341; cv=none; d=google.com; s=arc-20160816; b=DU8YLAKgZt3HUSx5dZdH9N01cX2QsABSqmH3g83EZSqkqgN3IpYZ9Z1H0Tr1VN2dTo iKCfqMAVEVsqA19nP4US+mWIAxXy20k9McwrWkqC486ZAOf7K6WGeAjfgfIqXElRjKEv MrSMEetOonXPoyT9j+uvNOBkKfHpmPP8fIsbnTIau3ppIUAESxOgJTvbU9IvWZr4LNB4 xtT51OCt5FKOz8mgT8xEDTBPpqN4o6oP5jqR4Po05S5cffmDSoqiIfnV6eFJnLEQV7HJ GQXrS5CFM/N5p0EvlIjC2dxkLqj1k6ExcRhmpAoaKyb8ZkrWEcc77MR84CojBa5MuEhZ i9XQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date:dkim-signature; bh=0VWgUWCJrESjAiRVJSGl/hfEMVCosaUEGl+H8/WZhxY=; b=pKD5c17NHXS+XolUQjG1tR4BhXGRUEa+MG6KFpraWLsIoLGUhjeJLBOPUcYMmEdJTX 3iCf9dnwiqyqKLB7LPeKdjX8Mitb0SMfyPsdl1GS5ZzkO2anttGkVmf637R5p52SPeeH bbs8+1eaY2BN1DjXq3A01yMjnWpSeJP+NlUznHw4l0Wkmw2kFr/Q5Aa48vHD6l4FLFX9 urpNFNrXAclkVUXYYA6MKr1uG5ez4EYQEIPo26b7fcq8e65J/HV4PO1V0CiOBMxObfWa 1grHJJ4345jioAV7ZUY3rCLQk8Uc+K9jj7H0/8ZI6a6bFpYoqqtbJhAFND5IrA1R2iJn 29Ug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Tsfb41dF; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k11-20020a170902c40b00b001affb590635si3097572plk.23.2023.05.26.00.15.27; Fri, 26 May 2023 00:15:41 -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=@kernel.org header.s=k20201202 header.b=Tsfb41dF; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242343AbjEZHCv (ORCPT + 99 others); Fri, 26 May 2023 03:02:51 -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 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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 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.