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 5F6D6C36010 for ; Mon, 7 Apr 2025 11:04:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EDC196B000C; Mon, 7 Apr 2025 07:04:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E8C736B000D; Mon, 7 Apr 2025 07:04:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D2D8E6B000E; Mon, 7 Apr 2025 07:04:35 -0400 (EDT) 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 B4C666B000C for ; Mon, 7 Apr 2025 07:04:35 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 203DE5B2FC for ; Mon, 7 Apr 2025 11:04:36 +0000 (UTC) X-FDA: 83306964552.14.BC1ADA5 Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) by imf05.hostedemail.com (Postfix) with ESMTP id 108FB100007 for ; Mon, 7 Apr 2025 11:04:33 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazon201209 header.b=PZfJgFmx; dmarc=pass (policy=quarantine) header.from=amazon.com; spf=pass (imf05.hostedemail.com: domain of "prvs=18509ffea=kalyazin@amazon.co.uk" designates 52.95.48.154 as permitted sender) smtp.mailfrom="prvs=18509ffea=kalyazin@amazon.co.uk" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744023874; a=rsa-sha256; cv=none; b=VkBzU8wCRj2RYRRYCyvbskjJDW9xorwDs45o3rz784UUOMBLIOCuAC8g6nOoiqTOGamqj3 1qatVpD3xJZCWfXCGQaDow9ucvU8L9544xp9/eTEy7tJ1dW0JqFKUbeEVmd4Sfjtl9qePC JTxGJTp8QkS886wmVeviQmxlpjFZYVo= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazon201209 header.b=PZfJgFmx; dmarc=pass (policy=quarantine) header.from=amazon.com; spf=pass (imf05.hostedemail.com: domain of "prvs=18509ffea=kalyazin@amazon.co.uk" designates 52.95.48.154 as permitted sender) smtp.mailfrom="prvs=18509ffea=kalyazin@amazon.co.uk" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744023874; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=ZjRA+PTfzs7vIA+H3U+wmpf+wbxMWwp7rlbhH+fAXlM=; b=KZmHAyUDNXLgBHzxzAREdszUNzlpJvn/KcjGx9BBDrSoqSjWOGdAXaHgqp8F9vrvW19ZWE irJz/0SCwixYpenncLmvFCpBCtJ7rQjA/ExQ5SkONRx0+t8Tz8dmwT7DLSudVmqj2W8QvM bDT6+bDCafeVi2xgrDjaKj0G6peJQJA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1744023874; x=1775559874; h=message-id:date:mime-version:reply-to:subject:to: references:from:in-reply-to:content-transfer-encoding; bh=ZjRA+PTfzs7vIA+H3U+wmpf+wbxMWwp7rlbhH+fAXlM=; b=PZfJgFmxQbKqZXA5BaV1ccfThTUxKnHGfILtJ7UVioIidMwDdyd7f5Tf ZeY2/ztIAGu/DF1rdzMR7i3/X1Sszp9hadPtMLX5YUpuWbxDNkBSw6eh1 9qpHo0Ruv/zi5E38Bcu0SfKrS46cvoQz9jBYTBRBt6F55/Shcy9MJ5DF/ 4=; X-IronPort-AV: E=Sophos;i="6.15,194,1739836800"; d="scan'208";a="478128755" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO smtpout.prod.us-east-1.prod.farcaster.email.amazon.dev) ([10.43.8.2]) by smtp-border-fw-6001.iad6.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2025 11:04:31 +0000 Received: from EX19MTAEUB001.ant.amazon.com [10.0.10.100:44174] by smtpin.naws.eu-west-1.prod.farcaster.email.amazon.dev [10.0.10.171:2525] with esmtp (Farcaster) id 6feef606-9eb5-46eb-875a-5973d50aa482; Mon, 7 Apr 2025 11:04:30 +0000 (UTC) X-Farcaster-Flow-ID: 6feef606-9eb5-46eb-875a-5973d50aa482 Received: from EX19D022EUC002.ant.amazon.com (10.252.51.137) by EX19MTAEUB001.ant.amazon.com (10.252.51.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1544.14; Mon, 7 Apr 2025 11:04:30 +0000 Received: from [192.168.3.31] (10.106.83.24) by EX19D022EUC002.ant.amazon.com (10.252.51.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1544.14; Mon, 7 Apr 2025 11:04:29 +0000 Message-ID: Date: Mon, 7 Apr 2025 12:04:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: Subject: Re: [PATCH v3 0/6] KVM: guest_memfd: support for uffd minor To: "Liam R. Howlett" , Ackerley Tng , Vishal Annapurve , "Fuad Tabba" , , , , , , , , , , , , , , , , , , , , , , , , , References: <20250404154352.23078-1-kalyazin@amazon.com> <2iggdfimgfke5saxs74zmfrswgrxmmsyxzphq4mdfpj54wu4pl@5uiia4pzkxem> Content-Language: en-US From: Nikita Kalyazin Autocrypt: addr=kalyazin@amazon.com; keydata= xjMEY+ZIvRYJKwYBBAHaRw8BAQdA9FwYskD/5BFmiiTgktstviS9svHeszG2JfIkUqjxf+/N JU5pa2l0YSBLYWx5YXppbiA8a2FseWF6aW5AYW1hem9uLmNvbT7CjwQTFggANxYhBGhhGDEy BjLQwD9FsK+SyiCpmmTzBQJnrNfABQkFps9DAhsDBAsJCAcFFQgJCgsFFgIDAQAACgkQr5LK IKmaZPOpfgD/exazh4C2Z8fNEz54YLJ6tuFEgQrVQPX6nQ/PfQi2+dwBAMGTpZcj9Z9NvSe1 CmmKYnYjhzGxzjBs8itSUvWIcMsFzjgEY+ZIvRIKKwYBBAGXVQEFAQEHQCqd7/nb2tb36vZt ubg1iBLCSDctMlKHsQTp7wCnEc4RAwEIB8J+BBgWCAAmFiEEaGEYMTIGMtDAP0Wwr5LKIKma ZPMFAmes18AFCQWmz0MCGwwACgkQr5LKIKmaZPNTlQEA+q+rGFn7273rOAg+rxPty0M8lJbT i2kGo8RmPPLu650A/1kWgz1AnenQUYzTAFnZrKSsXAw5WoHaDLBz9kiO5pAK In-Reply-To: <2iggdfimgfke5saxs74zmfrswgrxmmsyxzphq4mdfpj54wu4pl@5uiia4pzkxem> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.106.83.24] X-ClientProxiedBy: EX19D010EUC002.ant.amazon.com (10.252.51.160) To EX19D022EUC002.ant.amazon.com (10.252.51.137) X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 108FB100007 X-Stat-Signature: wr9qsfwohhixykyuegw41aazir14dofu X-HE-Tag: 1744023873-807433 X-HE-Meta: U2FsdGVkX19fV2iMDlZQo5AuFi4OrNriw86EAEl/Dq3T4CIZAsTqbbQTI3TTRlLTClmduXgZ6+y4ncXsxVa/QarHsB0UjRQnEqTELI9tNzLdam1KzM8ECaYtUwaeKgGFgrShOitNgJC7LM4oLSuuXDiPivO1ZJh5eBTkKfSIfecY0XSRbtYs1+ea4dHK5Zy0GTakcWaAm/U62YlaMjXVsWXLeBIM/ftdXfMsWQZEY76c6bqKEfBV+D42YGfHD/nmlLgt5iQlJIyiodEc3pUSo3owxoa7s0dgwhdNeDVXXaiPQaZ9niTBJgcW19XhA39dUp7NrvOFuJzJGRvzLuZCAJkffJmZ+A4xafcKM6F4M9Vz3yaqTISO+NS13D+JRB75QSDhVaBVvXDe1MC+CxHTuDFTTZP11vY5nHZCEkYUKRCFHLoBR4bd/ldXIT7MAphpaIusUsvPq04KwHpjcCUWXBs7NrFaxe7YLgb/9MMEIuzhMiooQyPEFDaV7G9QoFnHnGCLvphLqOUWjYjGo4byjERZUdpg1LjgRA3oDR/M1fzX4/XOKBRx6J2t7dGvbya4T6hfCmOaHhgfckDkSfEDLa2ThPPsaUMoHH0JmvlWbQFiPz8x80D7uhNiqYrJz4SNDhAho+km6x+dtHZR994AEY4RKbDm0orvkT8THqV3JGBdyaR7PETKUuj2CeLqYvMrlr5rPHeIE++5QM+GHEFEJZpjzymUTHsFZqEeKugCYdw0G/nVEjyD0yAwElg2a7rI55cBbVXCK2yHdvTyLe5fn7KF3wV3REG0VcZmPPJm6l8JyPudt3NDh1upFbFkMSXxHwQbVuKE/B4/YSUDw8C7Nah+MTbSR6XOhpLpJy8QutAuZLFLDQxIfBIoby90lZsm9y+o0RCdB09qc8uDbs9/27bIgSdbQxGqmDE41voG9Q1pbNGn2CjSWak7jEuqZpaK5pHDrFjKwSoWAevZbJJ 735jFPop ltDee14MiZf74p4moVGdmYf6863LV8rY2WO8TqCkCJWHTZ9LPtUmhBb4MyxWw9muX8tp3YW9/0aW0pPaTAP7KbnLbJjskWCbJqrYm9TGGVYmU3NytDFJF39AoFTguJ4mlGrxkYY1ZOC+oD8TyxrQm5P/DkXHdj7sa2ioyPZhticnrrsCDbrMsL3htyNh0wh4yxQu1yP0Ot92RS6rEtMoXWH6MTqkRKkvgWi5+PiHBlVH09FuUoz2ieeU08hRfE7D2MeH19E97xS+WJu75jJtiTrW43WaxPQVPH2RZ1pYRbE7KR88e3p7oEq4kM5UBpxXnVWzWxPg8pWjhvTBw5vLhO0l/bX8xT7RT7SAk/Rg6+8QVV7onF8SOKAzUPuYSiLinsE+6ZvmxPNZ0NrDUl6+K3+bkbIuR0c6FA8ARtmMpdURUYgUgXgq1TOT2VLIgsPBqhXYfprUdAkd6TFjbkQyOuza9pHrhlcKel5DR X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 04/04/2025 18:12, Liam R. Howlett wrote: > +To authors of v7 series referenced in [1] > > * Nikita Kalyazin [250404 11:44]: >> This series is built on top of the Fuad's v7 "mapping guest_memfd backed >> memory at the host" [1]. > > I didn't see their addresses in the to/cc, so I added them to my > response as I reference the v7 patch set below. Hi Liam, Thanks for the feedback and for extending the list. > >> >> With James's KVM userfault [2], it is possible to handle stage-2 faults >> in guest_memfd in userspace. However, KVM itself also triggers faults >> in guest_memfd in some cases, for example: PV interfaces like kvmclock, >> PV EOI and page table walking code when fetching the MMIO instruction on >> x86. It was agreed in the guest_memfd upstream call on 23 Jan 2025 [3] >> that KVM would be accessing those pages via userspace page tables. > > Thanks for being open about the technical call, but it would be better > to capture the reasons and not the call date. I explain why in the > linking section as well. Thanks for bringing that up. The document mostly contains the decision itself. The main alternative considered previously was a temporary reintroduction of the pages to the direct map whenever a KVM-internal access is required. It was coming with a significant complexity of guaranteeing correctness in all cases [1]. Since the memslot structure already contains a guest memory pointer supplied by the userspace, KVM can use it directly when in the VMM or vCPU context. I will add this in the cover for the next version. [1] https://lore.kernel.org/kvm/20240709132041.3625501-1-roypat@amazon.co.uk/T/#m4f367c52bbad0f0ba7fb07ca347c7b37258a73e5 > >> In >> order for such faults to be handled in userspace, guest_memfd needs to >> support userfaultfd. >> >> Changes since v2 [4]: >> - James: Fix sgp type when calling shmem_get_folio_gfp >> - James: Improved vm_ops->fault() error handling >> - James: Add and make use of the can_userfault() VMA operation >> - James: Add UFFD_FEATURE_MINOR_GUEST_MEMFD feature flag >> - James: Fix typos and add more checks in the test >> >> Nikita > > Please slow down... > > This patch is at v3, the v7 patch that you are building off has lockdep > issues [1] reported by one of the authors, and (sorry for sounding harsh > about the v7 of that patch) the cover letter reads a bit more like an > RFC than a set ready to go into linux-mm. AFAIK the lockdep issue was reported on a v7 of a different change. I'm basing my series on [2] ("KVM: Mapping guest_memfd backed memory at the host for software protected VMs"), while the issue was reported on [2] ("KVM: Restricted mapping of guest_memfd at the host and arm64 support"), which is also built on top of [2]. Please correct me if I'm missing something. The key feature that is required by my series is the ability to mmap guest_memfd when the VM type allows. My understanding is no-one is opposed to that as of now, that's why I assumed it's safe to build on top of that. [2] https://lore.kernel.org/kvm/20250318161823.4005529-1-tabba@google.com/T/ [3] https://lore.kernel.org/all/diqz1puanquh.fsf@ackerleytng-ctop.c.googlers.com/T/ > > Maybe the lockdep issue is just a patch ordering thing or removed in a > later patch set, but that's not mentioned in the discovery email? > > What exactly is the goal here and the path forward for the rest of us > trying to build on this once it's in mm-new/mm-unstable? > > Note that mm-unstable is shared with a lot of other people through > linux-next, and we are really trying to stop breaking stuff on them. > > Obviously v7 cannot go in until it works with lockdep - otherwise none > of us can use lockdep which is not okay. > > Also, I am concerned about the amount of testing in the v7 and v3 patch > sets that did not bring up a lockdep issue.. > >> >> [1] https://lore.kernel.org/kvm/20250318161823.4005529-1-tabba@google.com/T/ >> [2] https://lore.kernel.org/kvm/20250109204929.1106563-1-jthoughton@google.com/T/ >> [3] https://docs.google.com/document/d/1M6766BzdY1Lhk7LiR5IqVR8B8mG3cr-cxTxOrAosPOk/edit?tab=t.0#heading=h.w1126rgli5e3 > > If there is anything we need to know about the decisions in the call and > that document, can you please pull it into this change log? > > I don't think anyone can ensure google will not rename docs to some > other office theme tomorrow - as they famously ditch basically every > name and application. > > Also, most of the community does not want to go to a 17 page (and > growing) spreadsheet to hunt down the facts when there is an acceptable > and ideal place to document them in git. It's another barrier of entry > on reviewing your code as well. > > But please, don't take this suggestion as carte blanche for copying a > conversation from the doc, just give us the technical reasons for your > decisions as briefly as possible. > > >> [4] https://lore.kernel.org/kvm/20250402160721.97596-1-kalyazin@amazon.com/T/ > > [1]. https://lore.kernel.org/all/diqz1puanquh.fsf@ackerleytng-ctop.c.googlers.com/ > > Thanks, > Liam