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;
Date:   Thu, 4 Aug 2022 00:16:48 +0000
From:   Sean Christopherson <seanjc@google.com>
To:     Kai Huang <kai.huang@intel.com>
Cc:     Paolo Bonzini <pbonzini@redhat.com>, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, Michael Roth <michael.roth@amd.com>,
        Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [PATCH v2 2/3] KVM: x86/mmu: Fully re-evaluate MMIO caching when
 SPTE masks change
Message-ID: <YusP8FaOCLvq3VFE@google.com>
References: <20220803224957.1285926-1-seanjc@google.com>
 <20220803224957.1285926-3-seanjc@google.com>
 <d924ec235d9b0fb27f80cb03b02b5c7d8466fec1.camel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d924ec235d9b0fb27f80cb03b02b5c7d8466fec1.camel@intel.com>
Precedence: bulk

On Thu, Aug 04, 2022, Kai Huang wrote:
> On Wed, 2022-08-03 at 22:49 +0000, Sean Christopherson wrote:
> > +void __init kvm_mmu_spte_module_init(void)
> > +{
> > +	/*
> > +	 * Snapshot userspace's desire to allow MMIO caching.  Whether or not
> > +	 * KVM can actually enable MMIO caching depends on vendor-specific
> > +	 * hardware capabilities and other module params that can't be resolved
> > +	 * until the vendor module is loaded, i.e. enable_mmio_caching can and
> > +	 * will change when the vendor module is (re)loaded.
> > +	 */
> > +	allow_mmio_caching = enable_mmio_caching;
> 
> ... Perhaps 'use_mmio_caching' or 'want_mmio_caching' is better as it reflects
> userspace's desire? Anyway let you decide.

Part of me likes "want_mmio_caching", but the module param really is only for
testing, i.e. any sane configuration always wants MMIO caching, but sometimes it's
explicitly disallowed purely so that KVM can mimic hardware that doesn't support
MMIO caching.