From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DC956C433F5 for ; Fri, 19 Nov 2021 13:56:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8102F61547 for ; Fri, 19 Nov 2021 13:56:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8102F61547 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id E045B6B0096; Fri, 19 Nov 2021 08:51:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DB3CB6B0098; Fri, 19 Nov 2021 08:51:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C54536B0099; Fri, 19 Nov 2021 08:51:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0022.hostedemail.com [216.40.44.22]) by kanga.kvack.org (Postfix) with ESMTP id B7ADA6B0096 for ; Fri, 19 Nov 2021 08:51:27 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 7182189B46 for ; Fri, 19 Nov 2021 13:51:17 +0000 (UTC) X-FDA: 78825816594.29.6BC9AC7 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf24.hostedemail.com (Postfix) with ESMTP id 059B1B0000AE for ; Fri, 19 Nov 2021 13:51:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637329876; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0MQ6EmX5xeBMO7143sm+kmalOXvvH8veZYgNdztafAY=; b=Du9s4mAvHjp3HTcNatjhyJ3KkDckrh1zfwF+jr9J7tVTUY1CrL3DfvyXUTHnLQHOe9Rno0 suBtY3F0jMozvjK2dV6+9taJfE+cvwqxmE/+wdEDYJ80TACvb3c4u2WGCrA7hu6Ypu+1H8 V3z1nmVNSaNiEo+61RmAq44xQqOo/lo= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-592-Zer__kKIPH2DsdfpJQz7AQ-1; Fri, 19 Nov 2021 08:51:15 -0500 X-MC-Unique: Zer__kKIPH2DsdfpJQz7AQ-1 Received: by mail-wm1-f70.google.com with SMTP id r129-20020a1c4487000000b00333629ed22dso5935193wma.6 for ; Fri, 19 Nov 2021 05:51:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=0MQ6EmX5xeBMO7143sm+kmalOXvvH8veZYgNdztafAY=; b=70ZcPPMO0OkiwPtMeu7RUv61L8b0sJxbmaONXrzNiVWY15In8iiw6X9q/11Y9/QLoO 6fu6sirn5hviVAlfaPC4oW2d0iizz5WuwlVsHEubXdHApAiNIyR4+sMOAyvn68x2WUls Vv2nC1ipIvK4hRF8jm3vol/37/MqsJJx49LtqTno0JoxUy4Knn3bNI16u8HOeUJL5Aux d3OQCe7Lny5uuTHDlSUcE25T2l8vcKj0LxeDZcp0OB9FhvDu0o1I4OURrfOx024YPHfQ oMIN8m/h+KDYKu+cDb4LQqBEsY0rU3CUIaCt1uYRbJDx/9I8U6NKVxlwx3kdXcHQnkZO O5TA== X-Gm-Message-State: AOAM531Sn5EWgB5rKrr7vJb6uywM7F+kBIBMJvZvfvXkQZ6GVD0bx/7w AhK5j+PeZ/7KdNE2KkNXQANsSVD5dF0IJm8qSnFvzuLg6CXxVc4bxagCokU+FOMG+36Kfrzh6yK jpE3btreV71M= X-Received: by 2002:a05:6000:1a45:: with SMTP id t5mr7549054wry.306.1637329874087; Fri, 19 Nov 2021 05:51:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJyguzOIQ4dtj/UgUT64libXTpwo03IBVeH470Oj9eTA/dOIJOsebKLkqM9WONqcZosshV46JQ== X-Received: by 2002:a05:6000:1a45:: with SMTP id t5mr7548995wry.306.1637329873829; Fri, 19 Nov 2021 05:51:13 -0800 (PST) Received: from [192.168.3.132] (p5b0c6271.dip0.t-ipconnect.de. [91.12.98.113]) by smtp.gmail.com with ESMTPSA id f15sm3823943wmg.30.2021.11.19.05.51.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Nov 2021 05:51:13 -0800 (PST) Message-ID: <942e0dd6-e426-06f6-7b6c-0e80d23c27e6@redhat.com> Date: Fri, 19 Nov 2021 14:51:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST To: Chao Peng , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, qemu-devel@nongnu.org Cc: Paolo Bonzini , Jonathan Corbet , Sean Christopherson , 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 , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, john.ji@intel.com, susie.li@intel.com, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com References: <20211119134739.20218-1-chao.p.peng@linux.intel.com> <20211119134739.20218-2-chao.p.peng@linux.intel.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20211119134739.20218-2-chao.p.peng@linux.intel.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 059B1B0000AE X-Stat-Signature: adrn3e4opfus6qbtxzuegpu36erxs1rr Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Du9s4mAv; spf=none (imf24.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1637329874-659377 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 19.11.21 14:47, Chao Peng wrote: > From: "Kirill A. Shutemov" > > The new seal type provides semantics required for KVM guest private > memory support. A file descriptor with the seal set is going to be used > as source of guest memory in confidential computing environments such as > Intel TDX and AMD SEV. > > F_SEAL_GUEST can only be set on empty memfd. After the seal is set > userspace cannot read, write or mmap the memfd. > > Userspace is in charge of guest memory lifecycle: it can allocate the > memory with falloc or punch hole to free memory from the guest. > > The file descriptor passed down to KVM as guest memory backend. KVM > register itself as the owner of the memfd via memfd_register_guest(). > > KVM provides callback that needed to be called on fallocate and punch > hole. > > memfd_register_guest() returns callbacks that need be used for > requesting a new page from memfd. > Repeating the feedback I already shared in a private mail thread: As long as page migration / swapping is not supported, these pages behave like any longterm pinned pages (e.g., VFIO) or secretmem pages. 1. These pages are not MOVABLE. They must not end up on ZONE_MOVABLE or MIGRATE_CMA. That should be easy to handle, you have to adjust the gfp_mask to mapping_set_gfp_mask(inode->i_mapping, GFP_HIGHUSER); just as mm/secretmem.c:secretmem_file_create() does. 2. These pages behave like mlocked pages and should be accounted as such. This is probably where the accounting "fun" starts, but maybe it's easier than I think to handle. See mm/secretmem.c:secretmem_mmap(), where we account the pages as VM_LOCKED and will consequently check per-process mlock limits. As we don't mmap(), the same approach cannot be reused. See drivers/vfio/vfio_iommu_type1.c:vfio_pin_map_dma() and vfio_pin_pages_remote() on how to manually account via mm->locked_vm . But it's a bit hairy because these pages are not actually mapped into the page tables of the MM, so it might need some thought. Similarly, these pages actually behave like "pinned" (as in mm->pinned_vm), but we just don't increase the refcount AFAIR. Again, accounting really is a bit hairy ... -- Thanks, David / dhildenb