Received-SPF: pass (google.com: domain of linux-kernel+bounces-17667-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Fri, 5 Jan 2024 10:37:21 +0100
From: Andrew Jones <ajones@ventanamicro.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 1/4] KVM: introduce CONFIG_KVM_COMMON
Message-ID: <20240105-f3084386048af455001fd2e3@orel>
References: <20240104205959.4128825-1-pbonzini@redhat.com>
 <20240104205959.4128825-2-pbonzini@redhat.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240104205959.4128825-2-pbonzini@redhat.com>

On Thu, Jan 04, 2024 at 03:59:56PM -0500, Paolo Bonzini wrote:
> CONFIG_HAVE_KVM is currently used by some architectures to either
> enabled the KVM config proper, or to enable host-side code that is
> not part of the KVM module.  However, the "select" statement in
> virt/kvm/Kconfig corresponds to a third meaning, namely to
> enable common Kconfigs required by all architectures that support
> KVM.
> 
> These three meanings can be replaced respectively by an
> architecture-specific Kconfig, by IS_ENABLED(CONFIG_KVM), or by
> a new Kconfig symbol that is in turn selected by the
> architecture-specific "config KVM".
> 
> Start by introducing such a new Kconfig symbol, CONFIG_KVM_COMMON.
> Unlike CONFIG_HAVE_KVM, it is selected by CONFIG_KVM, not by
> architecture code.
> 
> Fixes: 8132d887a702 ("KVM: remove CONFIG_HAVE_KVM_EVENTFD", 2023-12-08)
> Cc: Andrew Jones <ajones@ventanamicro.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  arch/arm64/kvm/Kconfig     | 1 +
>  arch/loongarch/kvm/Kconfig | 1 +
>  arch/mips/kvm/Kconfig      | 1 +
>  arch/powerpc/kvm/Kconfig   | 1 +
>  arch/riscv/kvm/Kconfig     | 1 +
>  arch/s390/kvm/Kconfig      | 1 +
>  arch/x86/kvm/Kconfig       | 1 +
>  virt/kvm/Kconfig           | 3 +++
>  8 files changed, 10 insertions(+)

Reviewed-by: Andrew Jones <ajones@ventanamicro.com>