From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Christopherson Date: Fri, 10 Feb 2023 01:27:59 +0000 Subject: [PATCH v2 2/7] KVM: arm64: Use kvm_arch_flush_remote_tlbs() In-Reply-To: <86o7q4zdcp.wl-maz@kernel.org> References: <20230126184025.2294823-1-dmatlack@google.com> <20230126184025.2294823-3-dmatlack@google.com> <86o7q4zdcp.wl-maz@kernel.org> Message-ID: List-Id: To: kvm-riscv@lists.infradead.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, Feb 08, 2023, Marc Zyngier wrote: > On Thu, 26 Jan 2023 18:40:20 +0000, David Matlack wrote: > > @@ -368,7 +367,6 @@ void kvm_flush_remote_tlbs(struct kvm *kvm) > > ++kvm->stat.generic.remote_tlb_flush; > > } > > For context, we currently have this: > > if (!kvm_arch_flush_remote_tlb(kvm) > || kvm_make_all_cpus_request(kvm, KVM_REQ_TLB_FLUSH)) > ++kvm->stat.generic.remote_tlb_flush; > > Is there any reason why we shouldn't move the KVM_REQ_TLB_FLUSH call > into the arch-specific helpers? This is architecture specific, even if > the majority of the supported architecture cannot do broadcast > invalidation like arm64 does. s390 and PPC don't implement kvm_arch_flush_remote_tlb() at all, forcing them to implement the function just to implement what everyone except ARM does doesn't seem like the right trade off. As usual, x86 is the real oddball. All other architectures either use the purely generic KVM_REQ_TLB_FLUSH or they don't. x86 is the only one that sometimes wants to fallback. I can't see a clean way around that though, especially since MIPS apparently needs a notification _and_ a generic flush. Can the ARM hook be inlined? That would eliminate the extra call and should allow the compiler to optimize out the conditional and the request. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A36A9624 for ; Fri, 10 Feb 2023 01:28:04 +0000 (UTC) Received: by mail-pl1-f176.google.com with SMTP id u9so4951120plf.3 for ; Thu, 09 Feb 2023 17:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Mnobgm7/BRwA5boztD22jzgEkU3wNnOY9D1aetlEf20=; b=csIO68IIOhsu6e+pdejTTT2+w48D/sWWLOeOIyNJYGX8uv7NM4VXMJmzIiRrpc2byB oNF30v46MfMUr/zM1Y9pIBSYlUDIVF+op3/R/inHFDRjbUPyvEWGmS8g+4aYPNOLXmI1 k4gFifjP8fAfy+Pj0D/2S3/yl0kgg472XcQ7oejDQhBv7j6e61xvYtTNJxFhtCLHkUR0 vwFGPM0W1k1+6VAy/nE3sRCRvI1WK//Zg5F92Z7EstjU8c++zH/a/c8dOrVkEQhduubT CTG0B3v3Gj7juI3iy68AbH4UWi8S6xjEzA/lWDNstS1PF9tuSuPj4tgHC/qRIAxoM46N zJcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Mnobgm7/BRwA5boztD22jzgEkU3wNnOY9D1aetlEf20=; b=jsmGfwxz57sLvv0lBf9+pUs6aLXOaz2cxiBKxIHddCzU6xjIumttn5/RHCH3ua/rCd QBpy1i0x9ZYsHayy0mrYd25z1D7txcV5vhSSXhm9kHpZGGaM4M6JGRv0eyadAWP5f4Jm R5cmuixES4Wckd+ZRCn/OJEw0gvWj0MgRrkDo8lCfYTvE9Zr3NGvSbeBbwmFcI8BnCa4 HeejCpYhyPiNdMtL2hsNFB09tVC0s49KGB1+RrHv2JntSNY9QZQCJXxxBXbw5pLd5I7Q sW4lkY1Ky+Q+BGpJHvEYk6gzhAfu9hvNKXKeZveGl25JevFqXKuyvtVom1FxJjxvo3Y4 4DzA== X-Gm-Message-State: AO0yUKV06c3IP72tzkKW1ZY2k/vGo5YHpoA+ocqik8RcFsYLmSsEalL9 5ms6hwev3ylgrJhB+aV/Yf1bvw== X-Google-Smtp-Source: AK7set9Obj4DfpjGpxNp3bHnBxnNHSIelzzZM7dkpr8wS73Skb7zUOHunDsTlPiKfqLt2v8la2CkZg== X-Received: by 2002:a17:903:264c:b0:198:af4f:de0c with SMTP id je12-20020a170903264c00b00198af4fde0cmr103011plb.12.1675992483947; Thu, 09 Feb 2023 17:28:03 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id jk11-20020a170903330b00b00198da1ce519sm2143807plb.111.2023.02.09.17.28.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Feb 2023 17:28:02 -0800 (PST) Date: Fri, 10 Feb 2023 01:27:59 +0000 From: Sean Christopherson To: Marc Zyngier Cc: David Matlack , Paolo Bonzini , James Morse , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Huacai Chen , Aleksandar Markovic , Anup Patel , Atish Patra , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, linux-mips@vger.kernel.org, kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, Raghavendra Rao Ananta Subject: Re: [PATCH v2 2/7] KVM: arm64: Use kvm_arch_flush_remote_tlbs() Message-ID: References: <20230126184025.2294823-1-dmatlack@google.com> <20230126184025.2294823-3-dmatlack@google.com> <86o7q4zdcp.wl-maz@kernel.org> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86o7q4zdcp.wl-maz@kernel.org> On Wed, Feb 08, 2023, Marc Zyngier wrote: > On Thu, 26 Jan 2023 18:40:20 +0000, David Matlack wrote: > > @@ -368,7 +367,6 @@ void kvm_flush_remote_tlbs(struct kvm *kvm) > > ++kvm->stat.generic.remote_tlb_flush; > > } > > For context, we currently have this: > > if (!kvm_arch_flush_remote_tlb(kvm) > || kvm_make_all_cpus_request(kvm, KVM_REQ_TLB_FLUSH)) > ++kvm->stat.generic.remote_tlb_flush; > > Is there any reason why we shouldn't move the KVM_REQ_TLB_FLUSH call > into the arch-specific helpers? This is architecture specific, even if > the majority of the supported architecture cannot do broadcast > invalidation like arm64 does. s390 and PPC don't implement kvm_arch_flush_remote_tlb() at all, forcing them to implement the function just to implement what everyone except ARM does doesn't seem like the right trade off. As usual, x86 is the real oddball. All other architectures either use the purely generic KVM_REQ_TLB_FLUSH or they don't. x86 is the only one that sometimes wants to fallback. I can't see a clean way around that though, especially since MIPS apparently needs a notification _and_ a generic flush. Can the ARM hook be inlined? That would eliminate the extra call and should allow the compiler to optimize out the conditional and the request. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5CC8EC05027 for ; Fri, 10 Feb 2023 01:28:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=JwwgFdV5fjPITM7Zk/C+rDQ7KxQqf8zIpog/unMICDI=; b=RkDfG/qQ33Byv0 /OuabhYkNKud0134+Iqm14ujw2JRa/vPrAL1DjGODaa51KPp/wXWrChtpwvC+HsJk2yLgtNvw58Rr KNBvmboC3vk8ef6XH3Ulnp24RTx9E6rDVNuOU8umK1yis7cRNuMtvzvck43CCsBwa+k9GvcQ5to6+ u74xV1hni87WIiECSJdyk1rouz8Qvi9cF8YA+ZCmnBu9+R4nxixeFiH0rsEGeR1c8h4luauUvbRPr Ycw21VOstfmFvUw5+pUhFnsKDlQ0tzBbOd4DmW6Fcnz1voiWaH+dvXy8z/VQTG8sSV/78lLsASpmC 6iCa+AmmFv9UQYelHWRw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQID3-003plB-2z; Fri, 10 Feb 2023 01:28:17 +0000 Received: from mail-pl1-x632.google.com ([2607:f8b0:4864:20::632]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQICy-003pj2-Pa for linux-riscv@lists.infradead.org; Fri, 10 Feb 2023 01:28:14 +0000 Received: by mail-pl1-x632.google.com with SMTP id z1so4930308plg.6 for ; Thu, 09 Feb 2023 17:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Mnobgm7/BRwA5boztD22jzgEkU3wNnOY9D1aetlEf20=; b=csIO68IIOhsu6e+pdejTTT2+w48D/sWWLOeOIyNJYGX8uv7NM4VXMJmzIiRrpc2byB oNF30v46MfMUr/zM1Y9pIBSYlUDIVF+op3/R/inHFDRjbUPyvEWGmS8g+4aYPNOLXmI1 k4gFifjP8fAfy+Pj0D/2S3/yl0kgg472XcQ7oejDQhBv7j6e61xvYtTNJxFhtCLHkUR0 vwFGPM0W1k1+6VAy/nE3sRCRvI1WK//Zg5F92Z7EstjU8c++zH/a/c8dOrVkEQhduubT CTG0B3v3Gj7juI3iy68AbH4UWi8S6xjEzA/lWDNstS1PF9tuSuPj4tgHC/qRIAxoM46N zJcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Mnobgm7/BRwA5boztD22jzgEkU3wNnOY9D1aetlEf20=; b=Pjo+oR3zjgC8BIG0hYISeTZhE7nIb/2kIIbQFZglhIHjj+8Iuzq43qCwKnA2rlHuUQ kWhOIzOneL5HkB6po2E/lQi810cDGAYbWtbdB+Ksp55pRxgUp67WNhKuRmQvZRPbXH6v bKO0ymhMu/nuGzsp3ITPWAGaAqQ2u6OgaRyYmEufLcYDEYXu8JSS/wD6u9TX9/REQDJV LceZLwFLI4yQVcKpuvLqvfEf/Zn5UISiLrDnyDHiCvqt8gT7eGAvdVgw9uiBuhZTa2wL Fmsv82Gh0gWAlxdQwdOW0dcWffhnKECtamaCAyErz9w1tNdljy3Rn7ch91buUXJ+UJ5b oEjg== X-Gm-Message-State: AO0yUKUL7/v2CPBOkbvjTIfEuG70YTDQ7bFkEksn7+nP8AL47KXp7sYt 36R4jXZPjGgi1g65Z0jZ5uvR3A== X-Google-Smtp-Source: AK7set9Obj4DfpjGpxNp3bHnBxnNHSIelzzZM7dkpr8wS73Skb7zUOHunDsTlPiKfqLt2v8la2CkZg== X-Received: by 2002:a17:903:264c:b0:198:af4f:de0c with SMTP id je12-20020a170903264c00b00198af4fde0cmr103011plb.12.1675992483947; Thu, 09 Feb 2023 17:28:03 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id jk11-20020a170903330b00b00198da1ce519sm2143807plb.111.2023.02.09.17.28.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Feb 2023 17:28:02 -0800 (PST) Date: Fri, 10 Feb 2023 01:27:59 +0000 From: Sean Christopherson To: Marc Zyngier Cc: David Matlack , Paolo Bonzini , James Morse , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Huacai Chen , Aleksandar Markovic , Anup Patel , Atish Patra , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, linux-mips@vger.kernel.org, kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, Raghavendra Rao Ananta Subject: Re: [PATCH v2 2/7] KVM: arm64: Use kvm_arch_flush_remote_tlbs() Message-ID: References: <20230126184025.2294823-1-dmatlack@google.com> <20230126184025.2294823-3-dmatlack@google.com> <86o7q4zdcp.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <86o7q4zdcp.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230209_172812_854201_9A0F2CDD X-CRM114-Status: GOOD ( 15.38 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Wed, Feb 08, 2023, Marc Zyngier wrote: > On Thu, 26 Jan 2023 18:40:20 +0000, David Matlack wrote: > > @@ -368,7 +367,6 @@ void kvm_flush_remote_tlbs(struct kvm *kvm) > > ++kvm->stat.generic.remote_tlb_flush; > > } > > For context, we currently have this: > > if (!kvm_arch_flush_remote_tlb(kvm) > || kvm_make_all_cpus_request(kvm, KVM_REQ_TLB_FLUSH)) > ++kvm->stat.generic.remote_tlb_flush; > > Is there any reason why we shouldn't move the KVM_REQ_TLB_FLUSH call > into the arch-specific helpers? This is architecture specific, even if > the majority of the supported architecture cannot do broadcast > invalidation like arm64 does. s390 and PPC don't implement kvm_arch_flush_remote_tlb() at all, forcing them to implement the function just to implement what everyone except ARM does doesn't seem like the right trade off. As usual, x86 is the real oddball. All other architectures either use the purely generic KVM_REQ_TLB_FLUSH or they don't. x86 is the only one that sometimes wants to fallback. I can't see a clean way around that though, especially since MIPS apparently needs a notification _and_ a generic flush. Can the ARM hook be inlined? That would eliminate the extra call and should allow the compiler to optimize out the conditional and the request. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AED89C05027 for ; Fri, 10 Feb 2023 01:29:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fz7ouzW6Zyd/7XljtcMPUNWy2iuffeS0HZm60BEmIyk=; b=VZwvEBl6WyFiDJ nbEqVLZKc9If1GaEarsuOvcPqQIextScbZjg9PO1vXZequQYPiBz/5/nJf6YUMAiDzEfFtRTolJD8 mlm8RE+h2uHPoH1RGdyNvIQFq6k+9IHQypi+J+FkhLpNbDww0C/VzpHNsd86mj8y+IZZ9GlFGBf1K ZX3sBjOX31w11N8yCDujKMIe9EjhpRh04xjHFu/+8KUGu5FiZz01+Ar993DFJ32v1H35aw+m7g+wT ihE+RqIKM39rnvotXAKuidrST1d8DiXsqJZVMCDExBZ83xDSBo7B8uVOGSXkfE1XFoFbP8XDYHzJ8 E053w+v80/8vWl4ij3wg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQID4-003plX-Kh; Fri, 10 Feb 2023 01:28:18 +0000 Received: from mail-pl1-x62a.google.com ([2607:f8b0:4864:20::62a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQICz-003pj1-Ks for linux-arm-kernel@lists.infradead.org; Fri, 10 Feb 2023 01:28:14 +0000 Received: by mail-pl1-x62a.google.com with SMTP id b5so4945405plz.5 for ; Thu, 09 Feb 2023 17:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Mnobgm7/BRwA5boztD22jzgEkU3wNnOY9D1aetlEf20=; b=csIO68IIOhsu6e+pdejTTT2+w48D/sWWLOeOIyNJYGX8uv7NM4VXMJmzIiRrpc2byB oNF30v46MfMUr/zM1Y9pIBSYlUDIVF+op3/R/inHFDRjbUPyvEWGmS8g+4aYPNOLXmI1 k4gFifjP8fAfy+Pj0D/2S3/yl0kgg472XcQ7oejDQhBv7j6e61xvYtTNJxFhtCLHkUR0 vwFGPM0W1k1+6VAy/nE3sRCRvI1WK//Zg5F92Z7EstjU8c++zH/a/c8dOrVkEQhduubT CTG0B3v3Gj7juI3iy68AbH4UWi8S6xjEzA/lWDNstS1PF9tuSuPj4tgHC/qRIAxoM46N zJcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Mnobgm7/BRwA5boztD22jzgEkU3wNnOY9D1aetlEf20=; b=6NoDecfVsXTI2Vhs6Ux5+P0TLNwV4oIsb86z4+p5M2VTDydjnIm6JEs7PGJOXXe2V8 fn41r2i77DpUglRNfPCluAv68gTLBugDN4nF8KiYLmp1LTQ4+uaVXF8YWEj+/KFAwR/2 U9aYlQxYm4kEKjmm370g3XUo0BmRlt9hNIHepezM/Rp9FWl++pvtq9/A+SG/D1A2xGqm w3aJrTLRX2tKhGJbxEcZjpYE0vtQkART+21HzaviaVWrnReucpQxEI6fNKjgh/pQZS2b KJje3gAe3s7jI3LsYFJ0wHCRx6kONUIcrBhHHZSARnmGjnd6wz+KwX2BGUW22HVIN3Zr RSwA== X-Gm-Message-State: AO0yUKUkL+GfdG0eUpdi3GsAsBp0hAy4HkvVR6F8YYNAlpZeZYXYqNB6 +y2yo23tml/Srah9eVoqhsxOYQ== X-Google-Smtp-Source: AK7set9Obj4DfpjGpxNp3bHnBxnNHSIelzzZM7dkpr8wS73Skb7zUOHunDsTlPiKfqLt2v8la2CkZg== X-Received: by 2002:a17:903:264c:b0:198:af4f:de0c with SMTP id je12-20020a170903264c00b00198af4fde0cmr103011plb.12.1675992483947; Thu, 09 Feb 2023 17:28:03 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id jk11-20020a170903330b00b00198da1ce519sm2143807plb.111.2023.02.09.17.28.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Feb 2023 17:28:02 -0800 (PST) Date: Fri, 10 Feb 2023 01:27:59 +0000 From: Sean Christopherson To: Marc Zyngier Cc: David Matlack , Paolo Bonzini , James Morse , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Huacai Chen , Aleksandar Markovic , Anup Patel , Atish Patra , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, linux-mips@vger.kernel.org, kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, Raghavendra Rao Ananta Subject: Re: [PATCH v2 2/7] KVM: arm64: Use kvm_arch_flush_remote_tlbs() Message-ID: References: <20230126184025.2294823-1-dmatlack@google.com> <20230126184025.2294823-3-dmatlack@google.com> <86o7q4zdcp.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <86o7q4zdcp.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230209_172813_690477_50CC0ACD X-CRM114-Status: GOOD ( 16.88 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Feb 08, 2023, Marc Zyngier wrote: > On Thu, 26 Jan 2023 18:40:20 +0000, David Matlack wrote: > > @@ -368,7 +367,6 @@ void kvm_flush_remote_tlbs(struct kvm *kvm) > > ++kvm->stat.generic.remote_tlb_flush; > > } > > For context, we currently have this: > > if (!kvm_arch_flush_remote_tlb(kvm) > || kvm_make_all_cpus_request(kvm, KVM_REQ_TLB_FLUSH)) > ++kvm->stat.generic.remote_tlb_flush; > > Is there any reason why we shouldn't move the KVM_REQ_TLB_FLUSH call > into the arch-specific helpers? This is architecture specific, even if > the majority of the supported architecture cannot do broadcast > invalidation like arm64 does. s390 and PPC don't implement kvm_arch_flush_remote_tlb() at all, forcing them to implement the function just to implement what everyone except ARM does doesn't seem like the right trade off. As usual, x86 is the real oddball. All other architectures either use the purely generic KVM_REQ_TLB_FLUSH or they don't. x86 is the only one that sometimes wants to fallback. I can't see a clean way around that though, especially since MIPS apparently needs a notification _and_ a generic flush. Can the ARM hook be inlined? That would eliminate the extra call and should allow the compiler to optimize out the conditional and the request. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel