Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1267057rwb; Wed, 16 Nov 2022 14:55:30 -0800 (PST) X-Google-Smtp-Source: AA0mqf6OEnJeeaMl70zbY5sCb6to5TAiBZQdjsq5BErN1Avi2kpwV2w+bjqpe30mp9lToZDlgPYa X-Received: by 2002:a63:d10c:0:b0:46e:b96d:192d with SMTP id k12-20020a63d10c000000b0046eb96d192dmr23085897pgg.418.1668639330323; Wed, 16 Nov 2022 14:55:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668639330; cv=none; d=google.com; s=arc-20160816; b=kVuL28vQ/zl6RnwtCBGwqDw7+lseBxnwoWukf1QGkux3kaL9GmTGZwSJcofZIuX6Dl HOGzcJlJBbENmqaOWkXw1AsBpcIv33MnV+0zcGLmmG5Wr086q6dNUYNzi2AK5IORORlr wqzxcuLMTAG+YrEqXivbQ1XHb0xxEidc3RnXnpJqDBV5PlBMs22qQkwAenxj961mJZR1 PfRDd6xrOk7Tqi0UqterT2Ni8E9mmKH/YkVY8TzBqMNWU/FfjTmpcMBM0uCkyNPXafIT hDmWDPkcurxb3Nh+TmOM0pXHlexiICgUmcFagybIQstA3Rj4TmSbDbCM/xOdyAyJeigC UTtQ== 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=QGkcU8bsAXTracYvItbCwnniUSLgMtAC897scf+9ddo=; b=YNYEDua12Q2wsfkL3cPfDsqlSafRaUADV8KaCmg0SGwZ6MWPrOh8yHR1ZsOnYsbNm2 Wn7maZBHHLJiTOycVuMnJOrOPWBXtBQ5eqHJk1kv0V9orMQSvJziE7B0QxcCyzdMHMCm Dc8vLzgfAmj/wdUB8ZNM2mHaVJxpcFq+BrL1qvXs9XOnCGo1zeOvgQDFH+CjlLJk+90K WzGupp2Rhn4itcRxNlnsA42DZdgNuNq198i52ke5oxKcwa1J9aWD+vlkMjwysVLCovhE LXHPnXGRMgEOTLMxNORLvzmKNUmbmh29IwH62Ejp1r2AzYoDPMtxoMjtkxs1Xq9UY6IM fOig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Yb4wKwuT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id oc13-20020a17090b1c0d00b00217b50ee7b6si3379355pjb.1.2022.11.16.14.55.18; Wed, 16 Nov 2022 14:55:30 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Yb4wKwuT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S234649AbiKPWYg (ORCPT + 90 others); Wed, 16 Nov 2022 17:24:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238781AbiKPWYV (ORCPT ); Wed, 16 Nov 2022 17:24:21 -0500 Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3FE326AEF2 for ; Wed, 16 Nov 2022 14:24:16 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id q71so229421pgq.8 for ; Wed, 16 Nov 2022 14:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=QGkcU8bsAXTracYvItbCwnniUSLgMtAC897scf+9ddo=; b=Yb4wKwuTq8SDmbVGc+P7ahM8KCEiEG3EeQYJnIBy43Yu4s+iC+yGjvQgmVRoCCNQD4 bFiXa2DlOoj+M6COODORifyN82jIJfcy0aF0ZJtT8PTph1kJcj2QMeh/X+0txTmE1L9e vjCm/+n4/Ca01rOL6VyR5fbnbwtckm/wl6rnzgA+2U9G86s1X+WQKo3mRqwdqt/NZj4i P3BxQwhuIeyDfA8UssWFkeXvKFbx/BZ4epGrEEpau+te7+rSV+HSw5cBzmIPmEEBr4ge 1bl1xkBDMVGhMoLkvC/hKl/ZnG4RNCOpP9NsjFm/3oC6Zxx7zYxZx28Lz46N2hnBOT/Z 8NoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=QGkcU8bsAXTracYvItbCwnniUSLgMtAC897scf+9ddo=; b=iPdrOmJ+ESGL8+WqpjRq1F1OwJSSyVA/pz5pnUD4hy6qswuh0Yi03v4wlOmJEPV1Ed UKYgivybGFt3CFvU7TdWyuDf9nguNlWCnqddI/CYtbevniZFdTPd9kcT0fpELVuAFacM iWhpOIjv5bU3YnYMy8z2BnA3q7qVIlLVhZF3iy8ctiAA7y76owTXverV1pPHA9F0ea75 snp01Bce++qDdVx1bCdyXgkye22OQAeKvfppzOEVeBKFdbNO8zV22tPcPtstZWr7VC6A MZsd2fSosMWNDRLuxEK/NzeV2CcKQvFnn3CPn1eB8SrsIEvLYLiQ0qC2DDw18bVltKhn E2Jg== X-Gm-Message-State: ANoB5pk1dD9hHgSX4h7l4u/+2ydHX8wSkK0EXojbADmO8beyEfmtrThk P+llvIUiAzCgR5B7lMz6u+1nfA== X-Received: by 2002:a63:560c:0:b0:476:9983:b4b5 with SMTP id k12-20020a63560c000000b004769983b4b5mr12164723pgb.516.1668637455542; Wed, 16 Nov 2022 14:24:15 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id k15-20020aa7972f000000b0056bbba4302dsm11324389pfg.119.2022.11.16.14.24.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Nov 2022 14:24:15 -0800 (PST) Date: Wed, 16 Nov 2022 22:24:11 +0000 From: Sean Christopherson To: Chao Peng Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , tabba@google.com, Michael Roth , mhocko@suse.com, Muchun Song , wei.w.wang@intel.com Subject: Re: [PATCH v9 5/8] KVM: Register/unregister the guest private memory regions Message-ID: References: <20221025151344.3784230-1-chao.p.peng@linux.intel.com> <20221025151344.3784230-6-chao.p.peng@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221025151344.3784230-6-chao.p.peng@linux.intel.com> X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 25, 2022, Chao Peng wrote: > +static int kvm_vm_ioctl_set_mem_attr(struct kvm *kvm, gpa_t gpa, gpa_t size, > + bool is_private) > +{ > + gfn_t start, end; > + unsigned long i; > + void *entry; > + int idx; > + int r = 0; > + > + if (size == 0 || gpa + size < gpa) > + return -EINVAL; > + if (gpa & (PAGE_SIZE - 1) || size & (PAGE_SIZE - 1)) > + return -EINVAL; > + > + start = gpa >> PAGE_SHIFT; > + end = (gpa + size - 1 + PAGE_SIZE) >> PAGE_SHIFT; > + > + /* > + * Guest memory defaults to private, kvm->mem_attr_array only stores > + * shared memory. > + */ > + entry = is_private ? NULL : xa_mk_value(KVM_MEM_ATTR_SHARED); > + > + idx = srcu_read_lock(&kvm->srcu); > + KVM_MMU_LOCK(kvm); > + kvm_mmu_invalidate_begin(kvm, start, end); > + > + for (i = start; i < end; i++) { > + r = xa_err(xa_store(&kvm->mem_attr_array, i, entry, > + GFP_KERNEL_ACCOUNT)); > + if (r) > + goto err; > + } > + > + kvm_unmap_mem_range(kvm, start, end); > + > + goto ret; > +err: > + for (; i > start; i--) > + xa_erase(&kvm->mem_attr_array, i); I don't think deleting previous entries is correct. To unwind, the correct thing to do is restore the original values. E.g. if userspace space is mapping a large range as shared, and some of the previous entries were shared, deleting them would incorrectly "convert" those entries to private. Tracking the previous state likely isn't the best approach, e.g. it would require speculatively allocating extra memory for a rare condition that is likely going to lead to OOM anyways. Instead of trying to unwind, what about updating the ioctl() params such that retrying with the updated addr+size would Just Work? E.g. diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 55b07aae67cc..f1de592a1a06 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -1015,15 +1015,12 @@ static int kvm_vm_ioctl_set_mem_attr(struct kvm *kvm, gpa_t gpa, gpa_t size, kvm_unmap_mem_range(kvm, start, end, attr); - goto ret; -err: - for (; i > start; i--) - xa_erase(&kvm->mem_attr_array, i); -ret: kvm_mmu_invalidate_end(kvm, start, end); KVM_MMU_UNLOCK(kvm); srcu_read_unlock(&kvm->srcu, idx); + + return r; } #endif /* CONFIG_KVM_GENERIC_PRIVATE_MEM */ @@ -4989,6 +4986,8 @@ static long kvm_vm_ioctl(struct file *filp, r = kvm_vm_ioctl_set_mem_attr(kvm, region.addr, region.size, set); + if (copy_to_user(argp, ®ion, sizeof(region)) && !r) + r = -EFAULT break; } #endif