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 3C5C3C04A6A for ; Wed, 2 Aug 2023 16:10:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229578AbjHBQKt (ORCPT ); Wed, 2 Aug 2023 12:10:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55344 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230028AbjHBQKt (ORCPT ); Wed, 2 Aug 2023 12:10:49 -0400 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 310C7171B for ; Wed, 2 Aug 2023 09:10:48 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-d2a7ec86216so5183741276.0 for ; Wed, 02 Aug 2023 09:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690992647; x=1691597447; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=J4aKHKt7aK1dph2vrDmFCSsCX7pNGRd0NMwM4bEJgp8=; b=zT0xCNei+dnr4osudv9CAX0NFIvpN9o/MM9DYDQ2quRiRk2ySEcgwiLx53XnB1e+LY cWfI4OmX27mBOaJ58zlzT26+ZLcNHSkLH9hi8/662YILNSSO1QkU4G145NcnSjse7Tfi xrBWi/aY8NG6dUaFl22owtMyugIfQwHdkO/hgFnA80wpzq4X517qJXwcuOIoXxcIvofm vONKX+ciK2E9BoSSjIdQ67NLAviV68y9PDQBJ3S/jrfYmNcLzOoOg269tqqWjlilRydM bYWsCmY8tkmpgydfPs6qY/prFitzHw68WvsqFmR4BcVKfrWapat3cp0d7IklIiRVq+z3 Zr2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690992647; x=1691597447; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=J4aKHKt7aK1dph2vrDmFCSsCX7pNGRd0NMwM4bEJgp8=; b=VzFD78gYnwlRIxUz2WWt0vvKUXQKK7hKZ+Lsj05uEzkcBSa7Rsqde41cf3fmf4N31p I0psqrL/20rJnqjxQiSuvpCbPOlIu8AbVCp/zvZT+LpGwdNbs4AMlc+HdsOIbQvaLeAD t7LviqmIil/vg6Ksjs6XHtbOzQ4EJoklNE44aajXBcSrQEFR1Atq+CoUQsOSQaF8IQA+ F44hff/vYqpSK64Eepe3feHuWi1XqPj3Ykd9t4N7RQ87l5vD94pYsppuREv+wFurNnR2 +DhKTfc99UZUywiNKdPMyAhTWDzvaUAYkOYx4yxzZS2S8lKmcYcYYkteXcVj4iMiXabQ XntQ== X-Gm-Message-State: ABy/qLZAPvvT3LDTkWQJJSCNyrsDiF9QfepYMpFtXpDtAjtBCwrctfli mTA8i7cFr7sRJkgcdZKix/C7dKAWhHY= X-Google-Smtp-Source: APBJJlEeZC4NdvQKtmvRvpxiJWd4xeVqmT7pbWiugvK9iOofl4skg4f0sy48sXdlWulLCE9MeEDt/9unkzk= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:ab0b:0:b0:d0e:e780:81b3 with SMTP id u11-20020a25ab0b000000b00d0ee78081b3mr101602ybi.2.1690992647424; Wed, 02 Aug 2023 09:10:47 -0700 (PDT) Date: Wed, 2 Aug 2023 09:10:46 -0700 In-Reply-To: <878ratqw2l.wl-maz@kernel.org> Mime-Version: 1.0 References: <20230722022251.3446223-1-rananta@google.com> <20230722022251.3446223-2-rananta@google.com> <87v8e5r6s6.wl-maz@kernel.org> <878ratqw2l.wl-maz@kernel.org> Message-ID: Subject: Re: [PATCH v7 01/12] KVM: Rename kvm_arch_flush_remote_tlb() to kvm_arch_flush_remote_tlbs() From: Sean Christopherson To: Marc Zyngier Cc: Raghavendra Rao Ananta , Oliver Upton , James Morse , Suzuki K Poulose , Paolo Bonzini , Huacai Chen , Zenghui Yu , Anup Patel , Atish Patra , Jing Zhang , Reiji Watanabe , Colton Lewis , David Matlack , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Gavin Shan , "Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?=" , Shaoqin Huang Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Wed, Aug 02, 2023, Marc Zyngier wrote: > On Tue, 01 Aug 2023 01:42:54 +0100, > Raghavendra Rao Ananta wrote: > > Thanks for the suggestions; I can go with a common declaration. Along > > with that, do we want to keep defining > > __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS in the arch code that supports it or > > convert it into a CONFIG_? > > This isn't something that a user can select, more something that is an > architectural decision. Maybe in a later patch if there is a consensus > around that, but probably not as part of this series. +1. I agree it's annoying that KVM uses a mix of Kconfigs and manual #defines for the various "KVM_HAVE" knobs, but we have so many of both that one-off conversions without a real need don't make much sense.