Received: by 2002:a05:6358:7058:b0:131:369:b2a3 with SMTP id 24csp2404037rwp; Fri, 14 Jul 2023 05:51:30 -0700 (PDT) X-Google-Smtp-Source: APBJJlG7/C/km8Psji1dJB9V6DyHRLJgfPgh4e3erngC0WUwp+56zShg+fbs3e4GNRxalU38q8hu X-Received: by 2002:a17:907:58d:b0:991:b554:e64b with SMTP id vw13-20020a170907058d00b00991b554e64bmr4066571ejb.54.1689339090036; Fri, 14 Jul 2023 05:51:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689339090; cv=none; d=google.com; s=arc-20160816; b=0A9zror/fs7t4m/3Znv/vmSRi3cnIM0ryBTj9Z6qEX/iPbUx4kGjic14gLVTScF0cD k5Ti8VGycLS+FKfz0Nt6umFo1HJFfB+8qP41FYcU+ko9OUoLxhwDEgjuYhHxIl7YL33m ce2tKCjQaf4SOQyCAyPFfxi1xGMeia76VAfHBdfoqGsnGaoCqcrFPpXUtOyjY7wPw3y8 shSYdOlVtNDMcI7jTGRGG1QjIMaiFDbssAF+VwrAKnTH+PFAvVkEiNBiuEte8svr1tJZ Ag5R0YGSuX9CSMCqPQaHzkO9GyflSzktotR+sZYicOGZroe7waqeapglYPoMs5r1Z1q7 XU9Q== 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=F67T+nd0d/xU28PM2Ke7Qq6jJB19xYV1yyhEpAhfQkw=; fh=88kWLdG1vMWuaSB0MVOl6+MMLV8kNfbm9ZyBdrlSZvg=; b=OozAMFfwNu37lTZrkWRKfzgqQOlBYRZqPf1T2yz6Jrr6jJIygVO73hOTaAu0Uf8oVR WRJ1sRT+omJ786I8PEVdUqQXKnjDKDd59ol4GiFKBnqfEhvUyJpeViqIATkDL4seUcgs X+W6d5yN2gS+Uu8DtreOXcRlmI3kF1QG8xbK3qMZuDD4x7fuvBHD0hVabQSoPOMIRV6L IAQy1uVxj5YcRYT2le43Ka0hhmM8WN0K8jGyqDGsShWAjZFfw0mrZQ8X459tJiBmxVh5 Tm9Qq32nZAT0jE4qZj0rq3BSE8a9RhTTnwfFMaz0Sqp7YWqDHxRcAzgf6GjxXCxXFuoP UX+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=UuZ0XE83; 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 xo19-20020a170907bb9300b0098d22334ee0si9137991ejc.797.2023.07.14.05.51.05; Fri, 14 Jul 2023 05:51:30 -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=UuZ0XE83; 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 S230470AbjGNMNe (ORCPT + 99 others); Fri, 14 Jul 2023 08:13:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59300 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235518AbjGNMNb (ORCPT ); Fri, 14 Jul 2023 08:13:31 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1DD722722; Fri, 14 Jul 2023 05:13:30 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id AE60061CF8; Fri, 14 Jul 2023 12:13:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC74AC433C7; Fri, 14 Jul 2023 12:13:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689336809; bh=mWkDHkZl+VbW8o1b0RsUyRG5AF0ByNkcZoOfPpiApzQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UuZ0XE83FMN9J4tSNwzLvCgw9ZnbZX4PPYRV2GO/4qxffRYC/DTawTyW2ZM+NjFuJ xXBIUckgA3xiUQWUyXbdvU8McH2xv1sKdMmRe2yWLzPaJm9ByFyI6nKbPBpiNFNcFP 3hqz2S96Y0iDWCGl8nZ/32fQoC0KC8MwyPM8U2tLelX7b24oGzAMRpapLuOYKUKkx3 DZLb1d3KI71CtsEXOBSWKiwO+s6GtvkfzeQqi6s7lj9wMysXeikNmU1KPZbKaOhsFP yP+FEXRSW1dPIAV11cJBZJ2v0hIv9sJahFoYLpfoUoOwxmOR488n8kHm+Fr7Z0P2ut Rix5WH98gEW2Q== Date: Fri, 14 Jul 2023 13:13:21 +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: <20230714121321.GB5597@willie-the-truck> References: <20230509204801.2824351-1-quic_eberman@quicinc.com> <20230509204801.2824351-11-quic_eberman@quicinc.com> <20230519115948.GB2637@willie-the-truck> <20230605141839.GD21212@willie-the-truck> <3bd86221-ee2e-d157-009b-11f6ada98537@quicinc.com> <04605642-cad8-1701-ff41-63f2f00ba5f6@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04605642-cad8-1701-ff41-63f2f00ba5f6@quicinc.com> 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 On Thu, Jul 13, 2023 at 01:28:34PM -0700, Elliot Berman wrote: > On 6/22/2023 4:56 PM, Elliot Berman wrote: > > On 6/7/2023 8:54 AM, Elliot Berman wrote: > > > On 6/5/2023 7:18 AM, Will Deacon wrote: > > > > On Fri, May 19, 2023 at 10:02:29AM -0700, Elliot Berman wrote: > > > > > 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 thought pKVM was only holding off on upstreaming changes related > > > to guest-private memory? > > > > > > > > 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. > > > > > > Gunyah doesn't support swapping pages out while the guest is running > > > and the design of Gunyah isn't made to give host kernel full control > > > over the S2 page table for its guests. As best I can tell from > > > reading the respective drivers, ACRN and Nitro Enclaves both GUP pin > > > guest memory pages prior to giving them to the guest, so I don't > > > think this requirement from Gunyah is particularly unusual. > > > > > > > I read/dug into mmu notifiers more and I don't think it matches with > > Gunyah's features today. We don't allow the host to freely manage VM's > > pages because it requires the guest VM to have a level of trust on the > > host. Once a page is given to the guest, it's done for the lifetime of > > the VM. Allowing the host to replace pages in the guest memory map isn't > > part of any VM's security model that we run in Gunyah. With that > > requirement, longterm pinning looks like the correct approach to me. > > Is my approach of longterm pinning correct given that Gunyah doesn't allow > host to freely swap pages? No, I really don't think a longterm GUP pin is the right approach for this. GUP pins in general are horrible for the mm layer, but required for cases such as DMA where I/O faults are unrecoverable. Gunyah is not a good justification for such a hack, and I don't think you get to choose which parts of the Linux mm you want and which bits you don't. In other words, either carve out your memory and pin it that way, or implement the proper hooks for the mm to do its job. Will