linux-kernel - RE: [PATCH v2 02/27] KVM: x86/mmu: Factor out helper to get max mapping size of a memslot

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]

Message-ID: <DS0PR11MB6373DA9C535E2EAA54E38AADDCB99@DS0PR11MB6373.namprd11.prod.outlook.com>
Date:   Mon, 13 Mar 2023 15:37:05 +0000
From:   "Wang, Wei W" <wei.w.wang@...el.com>
To:     "Christopherson,, Sean" <seanjc@...gle.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Zhenyu Wang <zhenyuw@...ux.intel.com>,
        "Wang, Zhi A" <zhi.a.wang@...el.com>
CC:     "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "intel-gvt-dev@...ts.freedesktop.org" 
        <intel-gvt-dev@...ts.freedesktop.org>,
        "intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Zhao, Yan Y" <yan.y.zhao@...el.com>,
        Ben Gardon <bgardon@...gle.com>
Subject: RE: [PATCH v2 02/27] KVM: x86/mmu: Factor out helper to get max
 mapping size of a memslot

On Saturday, March 11, 2023 8:23 AM, Sean Christopherson wrote:
> Extract the memslot-related logic of kvm_mmu_max_mapping_level() into a
> new helper so that KVMGT can determine whether or not mapping a 2MiB
> page into the guest is (dis)allowed per KVM's memslots.
> 
> No functional change intended.
> 
> Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> ---
>  arch/x86/kvm/mmu/mmu.c          | 21 +++++++++++++++------
>  arch/x86/kvm/mmu/mmu_internal.h |  2 ++
>  2 files changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index
> c8ebe542c565..4685c80e441b 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -3083,20 +3083,29 @@ static int host_pfn_mapping_level(struct kvm
> *kvm, gfn_t gfn,
>  	return level;
>  }
> 
> +int kvm_mmu_max_slot_mapping_level(const struct kvm_memory_slot *slot,
> +				   gfn_t gfn, int max_level)

It seems more common to be named "kvm_mmu_slot_max_mapping_level"
(we have other kvm_mmu_slot_* functions defined already)


> +{
> +	struct kvm_lpage_info *linfo;
> +
> +	for ( ; max_level > PG_LEVEL_4K; max_level--) {
> +		linfo = lpage_info_slot(gfn, slot, max_level);
> +		if (!linfo->disallow_lpage)
> +			break;
> +	}
> +	return max_level;
> +}
> +
>  int kvm_mmu_max_mapping_level(struct kvm *kvm,
>  			      const struct kvm_memory_slot *slot, gfn_t gfn,
>  			      int max_level)
>  {
> -	struct kvm_lpage_info *linfo;
>  	int host_level;
> 
>  	max_level = min(max_level, max_huge_page_level);

Better to also have this min(,) moved to the helper?
E.g. if max_huge_page_level has been 4KB, no need to check into lpage_info in the helper.