Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5839468pxb; Thu, 20 Jan 2022 05:45:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJzLog8HTfPZKn+GkItE8Z8IcCTNvCwkoOQOgfvCWyu1qhYbUIBhhaZP3q9bxM10KV7907CV X-Received: by 2002:a17:90b:1646:: with SMTP id il6mr10929834pjb.12.1642686310122; Thu, 20 Jan 2022 05:45:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642686310; cv=none; d=google.com; s=arc-20160816; b=IPUqPc8OcphdqfQwzqf6XyZcR+LePYvpX/Zgazsmm6RKjJUyuiugGiofixQItyvErW cA1/r1ZcCk6g5Xctq+4AXUz/5HyMQ9mOtJjxyPUIJuj998Z653S7qG0CxfFUGCef/jOM gEy1EO+XLj0e3etVNDbYsuVOFBdW+R7ur0vlR5yuR34n0dBO8KGQOPGhTgJ7mGKGlQAY Ww/8HsJxP5HtVzAmhLRVEJy0pDMxJCCYPdeNcVnGHOFjcFqcDTrePQjrluid994SHo12 kw0G0SM9ahzsVKSbu+mst694BXpVrZkHQnLGriDVOnYmP8gDdecJpt73YiO6ASgR/O5Y JIcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :from:references:cc:to:content-language:user-agent:mime-version:date :message-id; bh=DWcm1zBSKv8jOgJ9Kz1BC0B6qTEoa3KAqZGn9hraZII=; b=I8TbFNS7DtFx/CFWcTvTUsNO8H/WWnhr27JSKmznG4VRvTwiZ2d2gF+CIs09Dqfqh2 3SwxAm1U7QrwE2ed1v6MPgF6KiFu44a5xLlna/NC4cC8ylhBT/oijNqDerLPm2tfDQOL 4dMrjx6efvS3fSGoAcCFEuHSixjc2ETHDF3zAyOqA3mmZ0n89Pd4CTfdE6uA9549fgO6 U5xspFxoLYbhqQ7w/G07aVBJ8PXKQ7YOQT3no8ZzO/e0YoWEtBtVyedj4aKXnhzUWz8u 5Gi36+lHRc3sqropFafCzkHsAerUphEK4sZMlXpSWT3zDj9uxwMyeI2R9A+VALMzSxoa 7Ydw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b19si3058337plz.574.2022.01.20.05.44.55; Thu, 20 Jan 2022 05:45:10 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344413AbiARPCO (ORCPT + 99 others); Tue, 18 Jan 2022 10:02:14 -0500 Received: from vps-vb.mhejs.net ([37.28.154.113]:35652 "EHLO vps-vb.mhejs.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345850AbiARPB0 (ORCPT ); Tue, 18 Jan 2022 10:01:26 -0500 Received: from MUA by vps-vb.mhejs.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1n9pyn-00084x-Lw; Tue, 18 Jan 2022 16:01:01 +0100 Message-ID: <010ef70c-31a2-2831-a2a7-950db14baf23@maciej.szmigiero.name> Date: Tue, 18 Jan 2022 16:00:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Nikunj A Dadhania Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Brijesh Singh , Tom Lendacky , Peter Gonda , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Bonzini References: <20220118110621.62462-1-nikunj@amd.com> <20220118110621.62462-7-nikunj@amd.com> From: "Maciej S. Szmigiero" Subject: Re: [RFC PATCH 6/6] KVM: SVM: Pin SEV pages in MMU during sev_launch_update_data() In-Reply-To: <20220118110621.62462-7-nikunj@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Nikunj, On 18.01.2022 12:06, Nikunj A Dadhania wrote: > From: Sean Christopherson > > Pin the memory for the data being passed to launch_update_data() > because it gets encrypted before the guest is first run and must > not be moved which would corrupt it. > > Signed-off-by: Sean Christopherson > [ * Changed hva_to_gva() to take an extra argument and return gpa_t. > * Updated sev_pin_memory_in_mmu() error handling. > * As pinning/unpining pages is handled within MMU, removed > {get,put}_user(). ] > Signed-off-by: Nikunj A Dadhania > --- > arch/x86/kvm/svm/sev.c | 122 ++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 119 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > index 14aeccfc500b..1ae714e83a3c 100644 > --- a/arch/x86/kvm/svm/sev.c > +++ b/arch/x86/kvm/svm/sev.c > @@ -22,6 +22,7 @@ > #include > #include > > +#include "mmu.h" > #include "x86.h" > #include "svm.h" > #include "svm_ops.h" > @@ -490,6 +491,110 @@ static unsigned long get_num_contig_pages(unsigned long idx, > return pages; > } > > +#define SEV_PFERR_RO (PFERR_USER_MASK) > +#define SEV_PFERR_RW (PFERR_WRITE_MASK | PFERR_USER_MASK) > + > +static struct kvm_memory_slot *hva_to_memslot(struct kvm *kvm, > + unsigned long hva) > +{ > + struct kvm_memslots *slots = kvm_memslots(kvm); > + struct kvm_memory_slot *memslot; > + int bkt; > + > + kvm_for_each_memslot(memslot, bkt, slots) { > + if (hva >= memslot->userspace_addr && > + hva < memslot->userspace_addr + > + (memslot->npages << PAGE_SHIFT)) > + return memslot; > + } > + > + return NULL; > +} We have kvm_for_each_memslot_in_hva_range() now, please don't do a linear search through memslots. You might need to move the aforementioned macro from kvm_main.c to some header file, though. > +static gpa_t hva_to_gpa(struct kvm *kvm, unsigned long hva, bool *ro) > +{ > + struct kvm_memory_slot *memslot; > + gpa_t gpa_offset; > + > + memslot = hva_to_memslot(kvm, hva); > + if (!memslot) > + return UNMAPPED_GVA; > + > + *ro = !!(memslot->flags & KVM_MEM_READONLY); > + gpa_offset = hva - memslot->userspace_addr; > + return ((memslot->base_gfn << PAGE_SHIFT) + gpa_offset); > +} > + > +static struct page **sev_pin_memory_in_mmu(struct kvm *kvm, unsigned long addr, > + unsigned long size, > + unsigned long *npages) > +{ > + struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; > + struct kvm_vcpu *vcpu; > + struct page **pages; > + unsigned long i; > + u32 error_code; > + kvm_pfn_t pfn; > + int idx, ret = 0; > + gpa_t gpa; > + bool ro; > + > + pages = sev_alloc_pages(sev, addr, size, npages); > + if (IS_ERR(pages)) > + return pages; > + > + vcpu = kvm_get_vcpu(kvm, 0); > + if (mutex_lock_killable(&vcpu->mutex)) { > + kvfree(pages); > + return ERR_PTR(-EINTR); > + } > + > + vcpu_load(vcpu); > + idx = srcu_read_lock(&kvm->srcu); > + > + kvm_mmu_load(vcpu); > + > + for (i = 0; i < *npages; i++, addr += PAGE_SIZE) { > + if (signal_pending(current)) { > + ret = -ERESTARTSYS; > + break; > + } > + > + if (need_resched()) > + cond_resched(); > + > + gpa = hva_to_gpa(kvm, addr, &ro); > + if (gpa == UNMAPPED_GVA) { > + ret = -EFAULT; > + break; > + } This function is going to have worst case O(n²) complexity if called with the whole VM memory (or O(n * log(n)) when hva_to_memslot() is modified to use kvm_for_each_memslot_in_hva_range()). That's really bad for something that can be done in O(n) time - look how kvm_for_each_memslot_in_gfn_range() does it over gfns. Thanks, Maciej