linux-kernel - Re: [PATCH v2 2/3] KVM: x86/mmu: Fully re-evaluate MMIO caching when SPTE masks change

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 4 Aug 2022 00:16:48 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Kai Huang <kai.huang@...el.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, Michael Roth <michael.roth@....com>,
        Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [PATCH v2 2/3] KVM: x86/mmu: Fully re-evaluate MMIO caching when
 SPTE masks change

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.