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 DA752C2BA1A for ; Fri, 21 Jun 2024 08:54:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5370C8D014B; Fri, 21 Jun 2024 04:54:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E6EA8D0138; Fri, 21 Jun 2024 04:54:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 388238D014B; Fri, 21 Jun 2024 04:54:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 186208D0138 for ; Fri, 21 Jun 2024 04:54:52 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B709FA2B5C for ; Fri, 21 Jun 2024 08:54:51 +0000 (UTC) X-FDA: 82254285582.12.4CF27C1 Received: from mail-vk1-f177.google.com (mail-vk1-f177.google.com [209.85.221.177]) by imf17.hostedemail.com (Postfix) with ESMTP id D98C140018 for ; Fri, 21 Jun 2024 08:54:49 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=03EsBiju; spf=pass (imf17.hostedemail.com: domain of tabba@google.com designates 209.85.221.177 as permitted sender) smtp.mailfrom=tabba@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718960085; h=from:from:sender: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:dkim-signature; bh=CYX2FT4NFr8Qk3CdgyGwyy67UucRagXIxiXFznR5hco=; b=3iNjx+MLmLHgZw5NgS9rz7ZUU5Jgc5tM7sWfRLXOvGlCKUHv+o5/jyLKkbPetywEWrr0/H GR0PPminf2nnIzH347ml4PdCd0sGtZs2Ool6+tTwa/Kq0bsDvdTOBMJTyQ7zYTgdkHcmNJ 1I0zVOFAR5EvzNbUwI9GgbkbiGnifJQ= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=03EsBiju; spf=pass (imf17.hostedemail.com: domain of tabba@google.com designates 209.85.221.177 as permitted sender) smtp.mailfrom=tabba@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718960085; a=rsa-sha256; cv=none; b=ayNrLuyfrA0ptNOcCsYPs2NZ/jukpG07tZxF3Sa4zCU7/gUaR8vN2tDSU1cFXwzLgs4ryA bqYntrrsPqFTAcGLg0/Wb0qdXWv6UcDLvD0YHHhGvi90KI4j43KiI6TQ3OjiaZdJVpBykd h6Kv8xUq8CvgoZ/nn9hIQHr1tOu4v4I= Received: by mail-vk1-f177.google.com with SMTP id 71dfb90a1353d-4ecf43f5537so904288e0c.0 for ; Fri, 21 Jun 2024 01:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1718960089; x=1719564889; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=CYX2FT4NFr8Qk3CdgyGwyy67UucRagXIxiXFznR5hco=; b=03EsBiju819yAQnm1/AHSDFc6M8EwHHin9AboUCn12XavgA8t+45bf904Gn5lg6Myp FS+UPSpX7xPV6kD2622OV7cmM6QxaOCMf8bVN+jsxlO/UdTe/T0ApMpY/2lWcaLBCYI4 MMsTg2Uq0f0KSIe7FxUxyUWyIH5Chs2bw4ilTM7z533Pt0rMUaVyiJmT5FIMjo+xipEJ DZOPp+3qrYGoMDJiAP0cGw7SuXJ0BQtft5Nmr7POB+J+vjRDz4I8YNEtffC1s7IQr3Wc sFTwTboC3DFK9jVuA4xZIlhjFgV0QmK4SJ4iWiyw2TvQDjDo+ogkDL0TCoJNu4aLsT8C Ay4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718960089; x=1719564889; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CYX2FT4NFr8Qk3CdgyGwyy67UucRagXIxiXFznR5hco=; b=XeMq9CBmgeIf9A2KEiUbsRBFLzAg9YiANI7b5RBVshEISaS3rddgIXr3aKchwEzJ5j iIFc1bqmBdyH0chmmSvODn6PCrAfCTQO7+ZhBS6EZUtPFuSc3Atjufz4X/RXE58gPzHo MCr68V9en5C20qiEGLEpGt+eBMOT+RWrF4SXqjsU8cfCxWSanmyimmWWBWsZCFhY/YZo 6xEkSdDrPCq8RBdd1K81U4AUTKd8XausX8PS1wlaVDKrwxOXUFm/ov2IQKgeJCJyqn7N YLkSZAbbHoNev6YyJMdTLkcqsMn/sR9qQpQUW9BtPetZZzk1KV3ESrZWgPKUdRBQwOiO x+Tw== X-Forwarded-Encrypted: i=1; AJvYcCVR4Tu/fLrZjEnKTyM42ei4ebrLdhweX5ylF60b7GS4RT8fl6lmNWLPEMdujpdq0r8Zt0eYgVJN7xzGscek9oycM+A= X-Gm-Message-State: AOJu0YymgSXvmYv4xERPq1D/GmIRYV7S75vZ2T1V8QFol0D8Eunjz9zp Cp2AMSZ3pK265roJK9XCQx77V5bWS2P+Y7K22A8WvIjsgciGqPAk8u8N8AE5JsJmuTpryzZZvo6 PovyeaXEn3Iy5AJ++w/ZdjJ48X2YOkGM0mI6s X-Google-Smtp-Source: AGHT+IE+4r9WRty/Arup00wvViToPFouwguOScRaXAgLBJYNMjH1J9pgCzwiTT3frpsC9/op0vu9j85DaYbfM+65eZo= X-Received: by 2002:a05:6122:3688:b0:4eb:e37:2d19 with SMTP id 71dfb90a1353d-4ef1a9e5b96mr9551360e0c.1.1718960088716; Fri, 21 Jun 2024 01:54:48 -0700 (PDT) MIME-Version: 1.0 References: <20240618-exclusive-gup-v1-0-30472a19c5d1@quicinc.com> <7fb8cc2c-916a-43e1-9edf-23ed35e42f51@nvidia.com> <14bd145a-039f-4fb9-8598-384d6a051737@redhat.com> <20240619115135.GE2494510@nvidia.com> <4c8b81a0-3a76-4802-875f-f26ff1844955@redhat.com> In-Reply-To: <4c8b81a0-3a76-4802-875f-f26ff1844955@redhat.com> From: Fuad Tabba Date: Fri, 21 Jun 2024 09:54:12 +0100 Message-ID: Subject: Re: [PATCH RFC 0/5] mm/gup: Introduce exclusive GUP pinning To: David Hildenbrand Cc: Sean Christopherson , Jason Gunthorpe , John Hubbard , Elliot Berman , Andrew Morton , Shuah Khan , Matthew Wilcox , maz@kernel.org, kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, pbonzini@redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: D98C140018 X-Stat-Signature: pteya7gfykx35y4o39rpt9zrsf1btp9q X-HE-Tag: 1718960089-868368 X-HE-Meta: U2FsdGVkX18rTgU9JCJgbtJLsYXXzGFhw/qqvwcAjO1AI9qUMBGSRJaXDDbTMlLfeVslA3fZdg+HijSf+g/QBA5RwF+OZGU7ggKkNJy31ornQv42UD5KFPnJzU8+5jcQTtFCOCrDboVHuQPqWaCxcFy3ZEQPaQyfHEjYG6kiYGonZOj6HNILve6rQTlEOCDrffhdVDuHPMDWZQRQL2E0GlozIU7OubYOo5iWvLfd60nFXxba6REoYp1RU8unQeljapVS3/wElLdV2s7FWWxS60BtH9AM3oq5SY3BH875JI8dx5//0OMUfYeMpeC6VncB1rfbbkBvSmvZTijltCxaUbxFhLon9x6AzpZ3vDc3BsSXBKKWf1oEHdobDIa1Sg59PE1NJvaxeX0LPQGO0RVXFl1iuMTZZ3B3I1wJ/tNHJ64cJrNlxO3Ef647+D7N1vvrGh2lr6J6LXZBybuSzr8O3LP1hgZPRKAVo0ORpsdFvps6lhcfTX5O8rNZg9OLivrMirYXCjnyP3vO4jfO4D9VtUIgwGY8NJd5GAIER9fn1e1oBeBKT0HGznDw1WzZ9xLuxP6gYOw+PIG+R1N6W2xf/TPA/AXe8ldR97RLrPn/eRSbGpnaGIQanKgv0DHSbDkfGF9G8ovh+o1R4VDHcEYi+zHXAevACnFHIWt4DtonHgmSn+/kMt6fbbbkaAB14VP5R7UsXAUeFrhimUGrS5FAkm67h/EyPeVsNsvIOKd85aKrcx65MsHBIhSe6EnksH99JGdd8LNJkP0YnSHdULasuMNy3qnBSDs1qHMhStVJfB0uCwOqh1yerXHQczB5l34XTw34GCxsCaazDZVBU02vJy+y5/hm9sOJfYOaleUIK7wN7piZKUy3uEeRa1tmgEhbJopFKvWa+QhfoJ2aDC5UxM+a72OfXqH7D0wVcmcygarY6T0z9poSTGGU3YixAFy6wibZosMnyq/SFfY7tPp NFzP9zFl 78Uo6kutc78SoPe8e6gHVRa7szo6kNsvCzj1VrCTifHCD6NQQrEgAJQjg/XITSfKyITtYwW8jfNBQ+/uOSfpAQcwqGXy38CiyGl3dl3DiwcvtJjqsqjWhn8AfpXqNH6wPfEp0pv3w3eWc73HRDchVFDMaWdljbZIgKEYDm4J0KEdLrvNvEhzy+aPvhMNZqKTqBgcrH+gSYSxqX9je1u/LWcuYH4K8kZF41BuD6kOfzSSgotHa5Ing9YAm+kCwdqOruOI+SK7f8ZL5k1xTYeoVwL0b0w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000034, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi David, On Fri, Jun 21, 2024 at 9:44=E2=80=AFAM David Hildenbrand wrote: > > >> Again from that thread, one of most important aspects guest_memfd is t= hat VMAs > >> are not required. Stating the obvious, lack of VMAs makes it really h= ard to drive > >> swap, reclaim, migration, etc. from code that fundamentally operates o= n VMAs. > >> > >> : More broadly, no VMAs are required. The lack of stage-1 page tabl= es are nice to > >> : have; the lack of VMAs means that guest_memfd isn't playing second= fiddle, e.g. > >> : it's not subject to VMA protections, isn't restricted to host mapp= ing size, etc. > >> > >> [1] https://lore.kernel.org/all/Zfmpby6i3PfBEcCV@google.com > >> [2] https://lore.kernel.org/all/Zg3xF7dTtx6hbmZj@google.com > > > > I wonder if it might be more productive to also discuss this in one of > > the PUCKs, ahead of LPC, in addition to trying to go over this in LPC. > > I don't know in which context you usually discuss that, but I could > propose that as a topic in the bi-weekly MM meeting. > > This would, of course, be focused on the bigger MM picture: how to mmap, > how how to support huge pages, interaction with page pinning, ... So > obviously more MM focused once we are in agreement that we want to > support shared memory in guest_memfd and how to make that work with core-= mm. > > Discussing if we want shared memory in guest_memfd might be betetr > suited for a different, more CC/KVM specific meeting (likely the "PUCKs" > mentioned here?). Sorry, I should have given more context on what a PUCK* is :) It's a periodic (almost weekly) upstream call for KVM. [*] https://lore.kernel.org/all/20230512231026.799267-1-seanjc@google.com/ But yes, having a discussion in one of the mm meetings ahead of LPC would also be great. When do these meetings usually take place, to try to coordinate across timezones. Cheers, /fuad > -- > Cheers, > > David / dhildenb >