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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82BE7C004D4 for ; Wed, 18 Jan 2023 08:24:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0115C6B0071; Wed, 18 Jan 2023 03:24:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F03606B0072; Wed, 18 Jan 2023 03:24:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA41B6B0074; Wed, 18 Jan 2023 03:24:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id CAB6A6B0071 for ; Wed, 18 Jan 2023 03:24:45 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 94858160BDE for ; Wed, 18 Jan 2023 08:24:45 +0000 (UTC) X-FDA: 80367233730.10.D89ADB3 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf06.hostedemail.com (Postfix) with ESMTP id 112CF18000F for ; Wed, 18 Jan 2023 08:24:42 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=mlv2RW74; spf=none (imf06.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 192.55.52.120) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674030283; h=from:from:sender:reply-to: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=WypZnTZ+iYZuTrdy9ZJF4+SMiwNrsvWgfqhfii2dj28=; b=TH5pagwdsjx1s1lqr1u86PPBSnAP0P35SIFMXzRtg5A+jTifooqAjlSMfEVPPco0jHqcHE VwPASv87FCfSbgc6WCWYdvKFg+PjpFsRoJ6ZS2AODXk7e4OcjuNshqARgNFHph4ES4oZYh P6AJO4gkJkn01roX0fpArmEYI4S2sQ4= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=mlv2RW74; spf=none (imf06.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 192.55.52.120) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674030283; a=rsa-sha256; cv=none; b=M1kmvKps/qoIyfeYr5fD4lgNfj1krtD1kFu8eENGd1qiacQyYlw0nK1Kn/X9n+Rua57y/f b9MzzKImDlqQmY2QcWuceJwMP2o+iolJnUxaDu7aHco/vwq2b82cFIznOpJWg+Vq0Ytg56 Av4MSu9gd+ABv1YlKfH4lSl2ExoOX/g= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1674030283; x=1705566283; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=mSO4PAMhEZisTll2SVfi2Yx3pBS6smLK7Q3mTuJU1oA=; b=mlv2RW74CdFHGIirJvyNM8ESA+Fr8oPKf1r0xiJBnsMfPqkdKL8FFkuf F336YBRwe4uOMw6FG6eiN4stoDefclcAIbzwhQyoosUHqQVcAA/J8wikZ c3OrSH84iOwTc2NdMS6ID3hcT96uHmF2X0IUL74lPGQZxOSsf5l3VD0Xe VPZy4AT8QCADZLOmF5mY0lQ33kzhJoPwuJC2XOF3kvmjseyjFsEbyeRcV Tnvn+jwGpp3Lc6exQiTL9dP3hHX86ulZTQvLEdlw8U4ZZJ6ybGCxNZ1G/ 3zgMQR+xRt0Pw7g9Ex205xRzqYBBV7M6kJvY+mFD8Vq5xoGn3GJov+alz Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10593"; a="323620024" X-IronPort-AV: E=Sophos;i="5.97,224,1669104000"; d="scan'208";a="323620024" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jan 2023 00:24:40 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10593"; a="722997271" X-IronPort-AV: E=Sophos;i="5.97,224,1669104000"; d="scan'208";a="722997271" Received: from chaop.bj.intel.com (HELO localhost) ([10.240.192.105]) by fmsmga008.fm.intel.com with ESMTP; 18 Jan 2023 00:24:28 -0800 Date: Wed, 18 Jan 2023 16:16:41 +0800 From: Chao Peng To: Sean Christopherson 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 , Arnd Bergmann , Naoya Horiguchi , Miaohe Lin , 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, wei.w.wang@intel.com Subject: Re: [PATCH v10 1/9] mm: Introduce memfd_restricted system call to create restricted user memory Message-ID: <20230118081641.GA303785@chaop.bj.intel.com> Reply-To: Chao Peng References: <20221202061347.1070246-1-chao.p.peng@linux.intel.com> <20221202061347.1070246-2-chao.p.peng@linux.intel.com> <20230117124107.GA273037@chaop.bj.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 3dzytukmo4gupaq39pfofwd6ghsgtydi X-Rspamd-Queue-Id: 112CF18000F X-HE-Tag: 1674030282-646348 X-HE-Meta: U2FsdGVkX1/FZyFkHhgcVXsN3xs7+XV06pfC70tOL9auEIBv8m5DNXKfSvs9VTZ8b8Oo3IuU9TJkO+m+WyKTn6YxY0Cqj7fIK0CX+dgPAaM6lRLtrV2XrKaoLtJGjs5tROJfS5XRIYhZOxPQ6HwAsBAbeEN5uSxjcwqobu35LFZLoAYsJGgIeaptXY4dmA9WSYxNyzHig1sbww8qsQrJf+0g79Yl0u1OxYkwAWMazOad9BW7bh1uY0sj/gWnJN/wazVIMv2uYq/qsPR+Uppi3VcL4pOoaaY0LOGO5S4TEm6bGo4qOcXdWKnuBmEdzVMMlrBY/D3HQ9xubbVOYMgWInbjUEiKGURV5jL9uZSycov2qx4xgJuxd7cudMFaJ8svPSONsyRWDlJbPuRpIk4XgniaU9LzGJ77evHiY9yMWHMunouky1BUqcG/KeSz7QIy5AVmyFNkfK56MJ5aeWG8viIBWRBs2HIpUuXocRqk7brXi2Bf3he3ge8iCBSHkydDO33pnHFdffgSiep7DplnVTR8eCJGbTT8zG4kdeB6n0hn6uz04gTQ7JiXfQexv4A/Y4WO9snj2MsQXfqH7UdEoyqIkyy15o+eIFx60ZiCZa51Jzj6FIp4pDPFlbCkS7BGmG+brnvZb/103H/ZVPoeJdb2L+RX9WBW34G3K4jNmIC7FWePb4jFunyPfFXckrDYOdO3rICzW+qylA/YusNxAueP3zrwVAx+ie+0ej1okK6b1HJ3E7KMV+V5xWqAzf0u6LNqBkUsXz3f0RPUboX+XmnZrbCr8YKAlhyTwieEoN88iFI9iIvqrdrHpYvHahhGRroWAAPcj1JVHFPNjcZn4zKTCa9JJnD29zOTu6FtrY/IglHiqf2Tf1VSKW3iz+EIOwVCT/QE2lXjDZX8m4FwxfCyZpgWdI3jTc8DSBvB+4K8/o4vdkXSzgp+Qwwfwob8UnbLhLvpOo51ti2XhNw 1l4KctIz 3nCGsqIfnhipLzgTiJLNreP2XYks6WHkSkn1G 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 Tue, Jan 17, 2023 at 04:34:15PM +0000, Sean Christopherson wrote: > On Tue, Jan 17, 2023, Chao Peng wrote: > > On Fri, Jan 13, 2023 at 09:54:41PM +0000, Sean Christopherson wrote: > > > > + list_for_each_entry(notifier, &data->notifiers, list) { > > > > + notifier->ops->invalidate_start(notifier, start, end); > > > > > > Two major design issues that we overlooked long ago: > > > > > > 1. Blindly invoking notifiers will not scale. E.g. if userspace configures a > > > VM with a large number of convertible memslots that are all backed by a > > > single large restrictedmem instance, then converting a single page will > > > result in a linear walk through all memslots. I don't expect anyone to > > > actually do something silly like that, but I also never expected there to be > > > a legitimate usecase for thousands of memslots. > > > > > > 2. This approach fails to provide the ability for KVM to ensure a guest has > > > exclusive access to a page. As discussed in the past, the kernel can rely > > > on hardware (and maybe ARM's pKVM implementation?) for those guarantees, but > > > only for SNP and TDX VMs. For VMs where userspace is trusted to some extent, > > > e.g. SEV, there is value in ensuring a 1:1 association. > > > > > > And probably more importantly, relying on hardware for SNP and TDX yields a > > > poor ABI and complicates KVM's internals. If the kernel doesn't guarantee a > > > page is exclusive to a guest, i.e. if userspace can hand out the same page > > > from a restrictedmem instance to multiple VMs, then failure will occur only > > > when KVM tries to assign the page to the second VM. That will happen deep > > > in KVM, which means KVM needs to gracefully handle such errors, and it means > > > that KVM's ABI effectively allows plumbing garbage into its memslots. > > > > It may not be a valid usage, but in my TDX environment I do meet below > > issue. > > > > kvm_set_user_memory AddrSpace#0 Slot#0 flags=0x4 gpa=0x0 size=0x80000000 ua=0x7fe1ebfff000 ret=0 > > kvm_set_user_memory AddrSpace#0 Slot#1 flags=0x4 gpa=0xffc00000 size=0x400000 ua=0x7fe271579000 ret=0 > > kvm_set_user_memory AddrSpace#0 Slot#2 flags=0x4 gpa=0xfeda0000 size=0x20000 ua=0x7fe1ec09f000 ret=-22 > > > > Slot#2('SMRAM') is actually an alias into system memory(Slot#0) in QEMU > > and slot#2 fails due to below exclusive check. > > > > Currently I changed QEMU code to mark these alias slots as shared > > instead of private but I'm not 100% confident this is correct fix. > > That's a QEMU bug of sorts. SMM is mutually exclusive with TDX, QEMU shouldn't > be configuring SMRAM (or any SMM memslots for that matter) for TDX guests. Thanks for the confirmation. As long as we only bind one notifier for each address, using xarray does make things simple. Chao