Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3745107pxj; Tue, 11 May 2021 10:57:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwusnvEVpRvT3Qho/XMeMSCo3AbBkuojbTHoiMMxqyxTCwzEBRNdjP56qSp7UNljSvOqAP/ X-Received: by 2002:a9d:7419:: with SMTP id n25mr26575945otk.1.1620755833343; Tue, 11 May 2021 10:57:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620755833; cv=none; d=google.com; s=arc-20160816; b=m8IXLt58RzecGPIywDcPv2nDAHxuq+aVMzMKRbFIyxlRmyeLUrrecLAa0FPcjUAxWa stR0/HiUWzeGEzkJFbiNCMG6EJf/YStEZzW8ADj6DXT3VXHCMULppzUxcLrrlsFkmtNH TFLYI1fP82sM3KlOWShet8tnv1taLb8PCwv/tTWt08DNyFzE+nq5t+EWOqrXkVkk/efN 3424PLz/BrCzYUqJtxmOvpnSVgC7S04h5hL+d1DsunXenao8mAV7IyCjTpqFb5mLvM3w ANZKT1AQgawBlF+RmgxqUQjpalWB+ovOKpVN3GXWoK+evJv7pEnA3Q19l51l2Q61a8Ud n6VA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=OE8q1BG05EipQ/1YaoTFUtsd5Q+5n/JYZoA2VhfSjZU=; b=d9VRTGQj67HJmEARqTF7nPpHCUfgbH0a+RkE4XTLywfV58R5TALTSMPtwj39PHvzNR U3u2JvPw8DkLyibWRqoHmHcGZuP7mY+iYRW1zm68dAFDt02RQHyIeuiTQS+pEVnpdfil ZYyKr+5q/2dv32Rz3eOm/kjwgPPIJN9tkl7MRXBFzrOic/r9UW8SDKBKcNT6OWPIojWb HTBIDjWuSF8IjBl1JW6bY7esQ1vkRCqyHzISZgrtEDyWUT56/8NWECusibvlacUOibWO ILjQ+sdPmhHjSZZotBh9+fOAu9iLwkoOM0cQ+2Jp3Slh6JFqgb36kPXuYRzsbR82g/HV nBPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=JhS+rcoD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o16si21086306otk.25.2021.05.11.10.56.58; Tue, 11 May 2021 10:57:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=JhS+rcoD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231793AbhEKR5X (ORCPT + 99 others); Tue, 11 May 2021 13:57:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39538 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231439AbhEKR5W (ORCPT ); Tue, 11 May 2021 13:57:22 -0400 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C19E5C06174A for ; Tue, 11 May 2021 10:56:14 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id gj14so12093353pjb.5 for ; Tue, 11 May 2021 10:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=OE8q1BG05EipQ/1YaoTFUtsd5Q+5n/JYZoA2VhfSjZU=; b=JhS+rcoDkQIqCU/PlBh5dmly1teXaDDZ4NNTzngHUkSjOcqPmik2eavfBztQGJnkid ZAbGDaTNBSN6Z0MUh6JR41JQxlgcjP95pshxWy5nk0tqEeOoerqY6aMUO1cs9b7+WH4p w/ZQnVrUPbvyMGctuPzObY2GMvlMz8qV0pkSonqbBEl/sxYb+6QQ0kfjEoCEx5a+cg0R ZUjr/6aa0ENfZqLct5o1Ho8tlCg45fKr2wY9E6A4NgPgiiIqewt8NFEKkAdEA19hM8WC BoC9OVHlQyVccMpNu12is+nE768jLMvOD0X5k/kOANjJpFfVkSbO46fmq5y4B9JoLxBy 4pzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=OE8q1BG05EipQ/1YaoTFUtsd5Q+5n/JYZoA2VhfSjZU=; b=akrSi1Lg8yqMksULjyo6mkmv2J8ROhUml/BddD6MwCM4FugaUoqr07/VYWcugdyH3/ tv/pvOaYsDiucK+fJgtkk2YmA8TPbe4SOoSih57O/3RfGLKrtKYqs++gzomLzWq/KaVZ V2MkhAy3Zp7va0CraY/hYFANAe4gMXiS0zanBFcxG2EdO179sCpSZ9TqKsKE2A4crMXH 28kkTHthR+oJUtYkbVibN66jzNCnqavP6CiV+SrJrHrq5nqkG73qp3fIpX/FVesj5t3k 1HQbG3StllvvOC+YkmS2/TDCR4NNS0TY7kxp3seUEcTXPTEoa+lQQMszJOzrotPUASfn H7vA== X-Gm-Message-State: AOAM530h9UtkuU0ZeQkRnUwOJBVzhtMz5AMORcTMnvJhNHaAsZLp6KIp 7USA3PQ8jJSu4ERO3LEBDp3f4g== X-Received: by 2002:a17:902:70c2:b029:ee:b4e5:64d5 with SMTP id l2-20020a17090270c2b02900eeb4e564d5mr30266317plt.77.1620755774157; Tue, 11 May 2021 10:56:14 -0700 (PDT) Received: from google.com (240.111.247.35.bc.googleusercontent.com. [35.247.111.240]) by smtp.gmail.com with ESMTPSA id o12sm14138270pjr.43.2021.05.11.10.56.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 May 2021 10:56:13 -0700 (PDT) Date: Tue, 11 May 2021 17:56:09 +0000 From: Sean Christopherson To: Ben Gardon Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Paolo Bonzini , Peter Xu , Peter Shier , Yulei Zhang , Wanpeng Li , Xiao Guangrong , Kai Huang , Keqian Zhu , David Hildenbrand Subject: Re: [PATCH v4 2/7] KVM: x86/mmu: Factor out allocating memslot rmap Message-ID: References: <20210511171610.170160-1-bgardon@google.com> <20210511171610.170160-3-bgardon@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210511171610.170160-3-bgardon@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 11, 2021, Ben Gardon wrote: > Small refactor to facilitate allocating rmaps for all memslots at once. > > No functional change expected. > > Signed-off-by: Ben Gardon > --- > arch/x86/kvm/x86.c | 39 ++++++++++++++++++++++++++++++--------- > 1 file changed, 30 insertions(+), 9 deletions(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 1e1f4f31e586..cc0440b5b35d 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -10911,10 +10911,35 @@ void kvm_arch_free_memslot(struct kvm *kvm, struct kvm_memory_slot *slot) > kvm_page_track_free_memslot(slot); > } > > +static int memslot_rmap_alloc(struct kvm_memory_slot *slot, > + unsigned long npages) > +{ > + int i; > + > + for (i = 0; i < KVM_NR_PAGE_SIZES; ++i) { > + int lpages; > + int level = i + 1; > + > + lpages = gfn_to_index(slot->base_gfn + npages - 1, > + slot->base_gfn, level) + 1; Might as well assign lpages at its declaration, i.e. int lpages = gfn_to_index(slot->base_gfn + npages - 1, slot->base_gfn, level) + 1; > + > + slot->arch.rmap[i] = > + kvcalloc(lpages, sizeof(*slot->arch.rmap[i]), > + GFP_KERNEL_ACCOUNT); Eh, I don't think avoiding a 3 char overrun is worth splitting across three lines. E.g. this is perfectly readable slot->arch.rmap[i] = kvcalloc(lpages, sizeof(*slot->arch.rmap[i]), GFP_KERNEL_ACCOUNT); Alternatively, the rmap size could be captured in a local var, e.g. const int sz = sizeof(*slot->arch.rmap[0]); ... slot->arch.rmap[i] = kvcalloc(lpages, sz, GFP_KERNEL_ACCOUNT); if (!slot->arch.rmap[i]) { memslot_rmap_free(slot); return -ENOMEM; } > + if (!slot->arch.rmap[i]) { > + memslot_rmap_free(slot); > + return -ENOMEM; Reaaaally getting into nitpicks, what do you think about changing this to a goto with the error handling at the bottom? Obviously not necessary by any means, but for me it makes it easier to see that all rmaps are freed on failure. My eyes skipped over that on the first read through. E.g. if (!slot_arch.rmap[i]) goto err; } return 0; err: memslot_rmap_free(slot); return -ENOMEM; > + } > + } > + > + return 0; > +} > + > static int kvm_alloc_memslot_metadata(struct kvm_memory_slot *slot, > unsigned long npages) > { > int i; > + int r; Personal preference, for short declarations like this I like putting 'em on a single line. > /* > * Clear out the previous array pointers for the KVM_MR_MOVE case. The > @@ -10923,7 +10948,11 @@ static int kvm_alloc_memslot_metadata(struct kvm_memory_slot *slot, > */ > memset(&slot->arch, 0, sizeof(slot->arch)); > > - for (i = 0; i < KVM_NR_PAGE_SIZES; ++i) { > + r = memslot_rmap_alloc(slot, npages); > + if (r) > + return r; > + > + for (i = 1; i < KVM_NR_PAGE_SIZES; ++i) { > struct kvm_lpage_info *linfo; > unsigned long ugfn; > int lpages; > @@ -10932,14 +10961,6 @@ static int kvm_alloc_memslot_metadata(struct kvm_memory_slot *slot, > lpages = gfn_to_index(slot->base_gfn + npages - 1, > slot->base_gfn, level) + 1; > > - slot->arch.rmap[i] = > - kvcalloc(lpages, sizeof(*slot->arch.rmap[i]), > - GFP_KERNEL_ACCOUNT); > - if (!slot->arch.rmap[i]) > - goto out_free; > - if (i == 0) > - continue; > - > linfo = kvcalloc(lpages, sizeof(*linfo), GFP_KERNEL_ACCOUNT); > if (!linfo) > goto out_free; > -- > 2.31.1.607.g51e8a6a459-goog >