Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp5727451rwd; Mon, 5 Jun 2023 07:49:14 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6hINZjFqAfngWHcT2WvtMVZocwtKosqzOdc592R7PqSinB9G/IEC3eQxjiw7LRPTHFxIOt X-Received: by 2002:a05:6a21:788d:b0:116:d935:f74b with SMTP id bf13-20020a056a21788d00b00116d935f74bmr2966693pzc.10.1685976553783; Mon, 05 Jun 2023 07:49:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685976553; cv=none; d=google.com; s=arc-20160816; b=imtzGMHjil4YfKIrFlEeYhFuaVRwgmEOor46wLGivvCfheYUpoJQRL6Ff5NhrgO0W8 WBauAazfyXsTf3Va+UqPFdrcMQkOcDxWHZgHFSytJwl54n0Dv6WrZJkyruFqfs77ml3P SftXS7y+ngc2Y+Che6MaiMwLupFqFeYrc1f7oQPMFr+zU4rr7l8ZZoYWxX09O3Kke1lE G8heqDqJZOs9nwoHuChBoW50aVfbVPIHurVtXAO3KqHI+3qNqb2EW8Cdd6NpDZymtsRi UjMcsIkaLcAnCkDAP6txUOmMdr3cae1aKO0YSIGcZKys15YKi/XfoztQa8KULczmiKW8 xjbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=yq/LAwQccBUVYbVnmcuNZ+A+kH0U6r811KXOUC2epLI=; b=bbgvi5OXEi9sk7elcTNmkw4gHJXGSXtp7VxaA7UCagvIHQPXtdZfGbsDa8U610mbGD hY1oCd2/YtyRrV+g0Nl7aPCCvb0Y2rXiw6i7dRTB4zis1yIJ+yIJLfem6ZONlHoTaZjP 4bt7oUAaY6k+T+DaWTPqVnrnO+Vybzd3iaj+ugq/eZm2dAij/bUwKNQ+Z0HNvmKrBDW+ QjbS+Cg+OwNq5NavdA6et22joXmHew53e07hWlWDaYtgFt6d9GuT3MKQfK894mqOCNRD xoYQG2H0v2Btob0n2IN6mvzbijDzHn5sgqRITj09Y+VTMR6SgYrjTK+h6mBNY6VPsMsZ 1ESw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=FvbA7sET; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w185-20020a6382c2000000b0053f2127278asi5846721pgd.788.2023.06.05.07.48.57; Mon, 05 Jun 2023 07:49:13 -0700 (PDT) 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=@kernel.org header.s=k20201202 header.b=FvbA7sET; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233862AbjFEOTB (ORCPT + 99 others); Mon, 5 Jun 2023 10:19:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47116 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233400AbjFEOS5 (ORCPT ); Mon, 5 Jun 2023 10:18:57 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6AAB10C; Mon, 5 Jun 2023 07:18:48 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 347D66241A; Mon, 5 Jun 2023 14:18:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 632DBC433EF; Mon, 5 Jun 2023 14:18:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685974727; bh=zq25hJ0fHK6GtehEcofkCZeAy8jNCWwt6NKJQEwBpSM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FvbA7sETZUW5ZcfTxbhvBaQKfBV28xcoqYaInME55BvENaD8mTZnOhJJubLqBfwas S2+KfwHil+AQh6U5BY7kxfxfsXzIRbc9Fm1jsuCYqwhPzADC3AiOKBuPyMSCT0XqyT cedzg8Vp/4wtQVT4K8gDNrunucZWVy+D0nvntkUiCe89JGFnvfxB/ML5apb7lEPBog eBDa4Md6P6ZWalE+1acYuyw8GgqeNvLOy8glnwIMA+6yqLP4YDQl+3oF6ZExl56ExD mffuTaNBhr+08U3L0Mdi2mJLHbRxkINhvTP/Ijb/8ECezrov4sJ5PhAhCoLumjP55S unYQlpAMd6HmQ== Date: Mon, 5 Jun 2023 15:18:39 +0100 From: Will Deacon To: Elliot Berman Cc: Alex Elder , Srinivas Kandagatla , Prakruthi Deepak Heragu , Murali Nalajala , Trilok Soni , Srivatsa Vaddagiri , Carl van Schaik , Dmitry Baryshkov , Bjorn Andersson , Konrad Dybcio , Arnd Bergmann , Greg Kroah-Hartman , Rob Herring , Krzysztof Kozlowski , Jonathan Corbet , Bagas Sanjaya , Andy Gross , Catalin Marinas , Jassi Brar , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, qperret@google.com Subject: Re: [PATCH v13 10/24] gunyah: vm_mgr: Add/remove user memory regions Message-ID: <20230605141839.GD21212@willie-the-truck> References: <20230509204801.2824351-1-quic_eberman@quicinc.com> <20230509204801.2824351-11-quic_eberman@quicinc.com> <20230519115948.GB2637@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 Hi Elliot, [+Quentin since he's looked at the MMU notifiers] Sorry for the slow response, I got buried in email during a week away. On Fri, May 19, 2023 at 10:02:29AM -0700, Elliot Berman wrote: > On 5/19/2023 4:59 AM, Will Deacon wrote: > > On Tue, May 09, 2023 at 01:47:47PM -0700, Elliot Berman wrote: > > > + ret = account_locked_vm(ghvm->mm, mapping->npages, true); > > > + if (ret) > > > + goto free_mapping; > > > + > > > + mapping->pages = kcalloc(mapping->npages, sizeof(*mapping->pages), GFP_KERNEL_ACCOUNT); > > > + if (!mapping->pages) { > > > + ret = -ENOMEM; > > > + mapping->npages = 0; /* update npages for reclaim */ > > > + goto unlock_pages; > > > + } > > > + > > > + gup_flags = FOLL_LONGTERM; > > > + if (region->flags & GH_MEM_ALLOW_WRITE) > > > + gup_flags |= FOLL_WRITE; > > > + > > > + pinned = pin_user_pages_fast(region->userspace_addr, mapping->npages, > > > + gup_flags, mapping->pages); > > > + if (pinned < 0) { > > > + ret = pinned; > > > + goto free_pages; > > > + } else if (pinned != mapping->npages) { > > > + ret = -EFAULT; > > > + mapping->npages = pinned; /* update npages for reclaim */ > > > + goto unpin_pages; > > > + } > > > > Sorry if I missed it, but I still don't see where you reject file mappings > > here. > > > > Sure, I can reject file mappings. I didn't catch that was the ask previously > and thought it was only a comment about behavior of file mappings. I thought the mention of filesystem corruption was clear enough! It's definitely something we shouldn't allow. > > This is also the wrong interface for upstream. Please get involved with > > the fd-based guest memory discussions [1] and port your series to that. > > > > The user interface design for *shared* memory aligns with > KVM_SET_USER_MEMORY_REGION. I don't think it does. For example, file mappings don't work (as above), you're placing additional rlimit requirements on the caller, read-only memslots are not functional, the memory cannot be swapped or migrated, dirty logging doesn't work etc. pKVM is in the same boat, but that's why we're not upstreaming this part in its current form. > I understood we want to use restricted memfd for giving guest-private memory > (Gunyah calls this "lending memory"). When I went through the changes, I > gathered KVM is using restricted memfd only for guest-private memory and not > for shared memory. Thus, I dropped support for lending memory to the guest > VM and only retained the shared memory support in this series. I'd like to > merge what we can today and introduce the guest-private memory support in > tandem with the restricted memfd; I don't see much reason to delay the > series. Right, protected guests will use the new restricted memfd ("guest mem" now, I think?), but non-protected guests should implement the existing interface *without* the need for the GUP pin on guest memory pages. Yes, that means full support for MMU notifiers so that these pages can be managed properly by the host kernel. We're working on that for pKVM, but it requires a more flexible form of memory sharing over what we currently have so that e.g. the zero page can be shared between multiple entities. Will