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 EC2ACC3ABAC for ; Tue, 6 May 2025 13:58:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1186F6B00A9; Tue, 6 May 2025 09:58:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C8DD6B00AA; Tue, 6 May 2025 09:58:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EABE46B00AB; Tue, 6 May 2025 09:58:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id C86046B00A9 for ; Tue, 6 May 2025 09:58:08 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E1C28C0296 for ; Tue, 6 May 2025 13:58:09 +0000 (UTC) X-FDA: 83412637098.06.CB43B23 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) by imf11.hostedemail.com (Postfix) with ESMTP id 0C2BB40005 for ; Tue, 6 May 2025 13:58:07 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=F7G+W+00; spf=pass (imf11.hostedemail.com: domain of 3bhUaaAYKCEk3plyunrzzrwp.nzxwty58-xxv6lnv.z2r@flex--seanjc.bounces.google.com designates 209.85.214.202 as permitted sender) smtp.mailfrom=3bhUaaAYKCEk3plyunrzzrwp.nzxwty58-xxv6lnv.z2r@flex--seanjc.bounces.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=1746539888; 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=Epkui4TROaYfaMdtDACEwRS7LcO5Q0jHyiEGdQbOTDo=; b=moNqzd5IxfkkUY9WPthPCsxF1Ak4JebmUAegB85f/RSmJz75ScxlBWqPzc+BnGgGFTb+MO J4ONN1l+MAnxn6GCOGbBkguN7mWIf+S7I5HgFmCPYM1WCIV42TmVFVXEMlGam5IPgKRo5t 200WgBSutAS0mWwFcRFuozc8Xd2d+gs= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=F7G+W+00; spf=pass (imf11.hostedemail.com: domain of 3bhUaaAYKCEk3plyunrzzrwp.nzxwty58-xxv6lnv.z2r@flex--seanjc.bounces.google.com designates 209.85.214.202 as permitted sender) smtp.mailfrom=3bhUaaAYKCEk3plyunrzzrwp.nzxwty58-xxv6lnv.z2r@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746539888; a=rsa-sha256; cv=none; b=1BbSDyaDPYjhRFr3C+SXlucl876PpMeXIPt9j6gd1WPiNbwcQr/7PqRkHcV6vPBY9HXLji e11MRqzqErT07IezxbZo9dCUfF3YCx/0Z+gCKYQ/rO6Ee0nQCgfhMDjwZ9FrgdeBffJsnn 2qGRgKhC7SYU3gqEq/YjiDRTKd+VUkU= Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-224347aef79so76315925ad.2 for ; Tue, 06 May 2025 06:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1746539887; x=1747144687; darn=kvack.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=Epkui4TROaYfaMdtDACEwRS7LcO5Q0jHyiEGdQbOTDo=; b=F7G+W+00NGLNshqtMawBc7d2ZaU3DcpjjRCh/x670uheiNSMdr3Hefk/f+10o0PXlH R43Z82yTKEJTw81bl785Xq11zQRNzEIn3Ngcn8IaOsd5Ou/RKCACYWZ3Zcp+J+X+jWSZ Kyt6y3kIAjAU/bAj9iWNDhQ2BvPffqQ1QtoQ8eT57LqvpgTygUdcSwci16QxjTrf6lFN ZQfDhvt1MIEJe6KLFQ1dOazVTuf0zCtRHkPhbR3gU6kJ5AsQyYO0Ez6pbgYtNuDwPXOD fjEhlyH+VTpJmB2BMBQSs8g3M1WTWrtuCHe8wZ+ZKoZzj6L8dytLnenFNfRH7CFyOhe7 c6Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746539887; x=1747144687; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=Epkui4TROaYfaMdtDACEwRS7LcO5Q0jHyiEGdQbOTDo=; b=r+ZdggRKLUl9u0MCLU9C+TiCseJMQ1Gj9Cw9dyPDPwzKwrCl4wm8k9CjXDDJ43s80y 08J2OF47eebnYYPsgRzMl2pYB2Mb4RQnQJ/ppq96Z6bhWAY5yRJgi0qnJ129lkLDGhgZ oIxS0MhzXa+/QWOqqOwiOF9DwY2WrprCQQL7z+p8JTBQO9eEyfhNaNbzBHGPhpjJ9bDI FWIX2TMEI+be8owAb89nqcFysaClEtmBD5v6xTx1+mv0iUVvoK99LsGZgi38bY7X0ufr 6+oTbqg8qYM+jZGREKfKa4uPlhMEcGD90v1Dz33kBXHdXY+coglLYIgqdwel4pUxLlfr dQ+A== X-Forwarded-Encrypted: i=1; AJvYcCU3cTiJB5Rtz95OxAfCz7xeHIpmnqFithNiJHaFLV/J6h369KzT/fcoCsNX/Ot9o52ZooSyqCayWw==@kvack.org X-Gm-Message-State: AOJu0Yyr9p5cPI9JrV/Fec7a6fvaQGZUNAFGUlf7kktfbKZbvE87aQgF mQkMIZUalVT/0fu+MpobLOSRfJYJlQlQrJAGzEjoMBt+0dhIta/fLiYa/zl5//sLHU8Ky9TMadB AFw== X-Google-Smtp-Source: AGHT+IHreTuRAhH/wUxgD8PQxg1UOE2znzyhgkrxDm9K+FWFaiZsk+OikDER4lrfDo4rClwDb4vAN5nmo08= X-Received: from plbml4.prod.google.com ([2002:a17:903:34c4:b0:223:536f:9461]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:8ce:b0:220:d078:eb33 with SMTP id d9443c01a7336-22e36366425mr50533145ad.36.1746539886699; Tue, 06 May 2025 06:58:06 -0700 (PDT) Date: Tue, 6 May 2025 06:58:04 -0700 In-Reply-To: Mime-Version: 1.0 References: <386c1169-8292-43d1-846b-c50cbdc1bc65@redhat.com> <7e32aabe-c170-4cfc-99aa-f257d2a69364@redhat.com> Message-ID: Subject: Re: [PATCH v8 06/13] KVM: x86: Generalize private fault lookups to guest_memfd fault lookups From: Sean Christopherson To: Vishal Annapurve Cc: David Hildenbrand , Ackerley Tng , Fuad Tabba , kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, pbonzini@redhat.com, chenhuacai@kernel.org, mpe@ellerman.id.au, anup@brainfault.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, viro@zeniv.linux.org.uk, brauner@kernel.org, willy@infradead.org, akpm@linux-foundation.org, xiaoyao.li@intel.com, yilun.xu@intel.com, chao.p.peng@linux.intel.com, jarkko@kernel.org, amoorthy@google.com, dmatlack@google.com, isaku.yamahata@intel.com, mic@digikod.net, vbabka@suse.cz, mail@maciej.szmigiero.name, michael.roth@amd.com, wei.w.wang@intel.com, liam.merwick@oracle.com, isaku.yamahata@gmail.com, kirill.shutemov@linux.intel.com, suzuki.poulose@arm.com, steven.price@arm.com, quic_eberman@quicinc.com, quic_mnalajal@quicinc.com, quic_tsoni@quicinc.com, quic_svaddagi@quicinc.com, quic_cvanscha@quicinc.com, quic_pderrin@quicinc.com, quic_pheragu@quicinc.com, catalin.marinas@arm.com, james.morse@arm.com, yuzenghui@huawei.com, oliver.upton@linux.dev, maz@kernel.org, will@kernel.org, qperret@google.com, keirf@google.com, roypat@amazon.co.uk, shuah@kernel.org, hch@infradead.org, jgg@nvidia.com, rientjes@google.com, jhubbard@nvidia.com, fvdl@google.com, hughd@google.com, jthoughton@google.com, peterx@redhat.com, pankaj.gupta@amd.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 0C2BB40005 X-Stat-Signature: exwr1kf576xftzjseb416puwhjzc3idr X-HE-Tag: 1746539887-29995 X-HE-Meta: U2FsdGVkX1+o2WCcCJf1LGeaWCGracZqvUc7T8XQTarhlZHQNoljMKdgqlh92L38mmKAa8xk2sFAgiM1nTx7MsMGePoR/8eh/VhPgVt13SRzmr9CDTHQSq/FgEvRFLIBFeyePIev5rCA871OPMpyK1W4V1BPqgJVyE90jh9nhS6XnIng4czLSeeWSZDZNYZ2Vc4m5DjQgo/AkQsZpul5t/XDkFAyewiLrLNZ4TZKxkRLo+5q02ObT20YJTzNG3/Hcb0UpH+yiMsJm5dreh6nbIi4CSYsHkt/vzZ8SXDzEovkbhXkBepqdj2NLhY+yopFkc7edyA9qZmPFZdtFAkJbDF5mF4+UFQPjoEho8puS5x5d8Js3cRl8HqhOko8G6q5f/nWQq84MwTruXB3w0ITk3cuqBSV1P8N65W+odCIvawhiik4sieJtY2NJwdMXuHfcxlpxoV2pY4u3Znzko20z6lkQSyFZV8NrqrxgKSJ0MVaLSZSG6SJBirwdJM8Bd+q9eobyld/1vmjZ47mPRrbMN4UBbpoEgbPUH7onBTqS+3gzhDdz6ZSbBqqIt8jlKlzPYZWkgisAIRgyLc4/XTuL5l1mHJTs40gDJbl6eOLJ++0cRGDF4SXEkjGtXvbiuLxeUmbAiwiDVjAo2AQ3AQcpo3MAK3qmJ4KXt0YiTD+8KwSTCKuJDZ2WlKd0jnUOxRZjxo5gmcWWW3eur8YVbajjq8Ii64Z7pHLBmuUOpXnOsP/U951JDews6esVajrH9cOaSHsvi6FDrTl/vL/WVzbMLyUSiP1az/xAlLL/SbHrEDQalkHvLJTjClDdZfAoQVEcxTHB2TW1zVNOzg8rkM+SxWZJ63WaT8Algb0aT93jNfRy+01+CD8dhBOkCp742/9JtpTyEeO+UeJ6/uZkNWwiBJBlWD4AxS4r8/N30GDHRgn2Ui/FaQ38DG0WxCHBkchdfx5EBCaOmU3yFg/t6j x+8csBwd JgXxuePTGmzdZ8vaSuLv4qUtv5WLLyQ/1Le/McbXSo3T8GjgrxhJ2WDASbaDTzjz+ubCTxovfwktJa0xMeF6svy2CY69AuAL6+wWpz70zvi9ZabYnmtQ81eW5PN0meBB0jPw1traVC88ab9Iw8ExznILZLOffPkH4PdzVmLepNJgjVJ9Q9UXbSxsPjii0XpmqGfd2PiKHakq9V16PorcSLcJzmgrZZRycF+NNMX4/r3JgC1EJ/Sc5Ks4C9hwGtOE7H9AHF4+eJxnmuZtpMxqUWPlCowuBHtpRobgL5ESjZbSYfkPnjfJ4AF4nJiZMHNo4r0aCHIrKgYrp6stafT1DTQiUlcmiGB96Utpxh2uxDmoC066mU6TYIPCpHdYJGnABf8S2id0pAGr9c8gQFL4ZlUKyJz296MAbyXf43O7dFC0BZaw/xlpVuUaf6n0g4C8mM+NnfkRiB+VhJfVLLf4/4qBOS2S45MrMxAj1yryekbhWv8vRk+FLYpuuUAjBLSO90lcxrNduq9GuB7/Pp+TvhUeSxe1UVP/dxhPeoTzOaTnMBPEdUcxblfb36Nu3mE50PjGzDthZjOMfNMHT06zjLwSU7eM0J3li5zUulUHnKRqpYZGeCVde73cYAFhDswmKOqX5U8hg3Mu2I0GzVEnz/FQyEqO0OtX3uI7GlQIfbVvhE1xfaxxjqqEn1q2O/t3cfWuM 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: List-Subscribe: List-Unsubscribe: On Mon, May 05, 2025, Vishal Annapurve wrote: > On Mon, May 5, 2025 at 10:17=E2=80=AFPM Vishal Annapurve wrote: > > > > On Mon, May 5, 2025 at 3:57=E2=80=AFPM Sean Christopherson wrote: > > > > ... > > > > And not worry about lpage_infor for the time being, until we actual= ly do > > > > support larger pages. > > > > > > I don't want to completely punt on this, because if it gets messy, th= en I want > > > to know now and have a solution in hand, not find out N months from n= ow. > > > > > > That said, I don't expect it to be difficult. What we could punt on = is > > > performance of the lookups, which is the real reason KVM maintains th= e rather > > > expensive disallow_lpage array. > > > > > > And that said, memslots can only bind to one guest_memfd instance, so= I don't > > > immediately see any reason why the guest_memfd ioctl() couldn't proce= ss the > > > slots that are bound to it. I.e. why not update KVM_LPAGE_MIXED_FLAG= from the > > > guest_memfd ioctl() instead of from KVM_SET_MEMORY_ATTRIBUTES? > > > > I am missing the point here to update KVM_LPAGE_MIXED_FLAG for the > > scenarios where in-place memory conversion will be supported with > > guest_memfd. As guest_memfd support for hugepages comes with the > > design that hugepages can't have mixed attributes. i.e. max_order > > returned by get_pfn will always have the same attributes for the folio > > range. Oh, if this will naturally be handled by guest_memfd, then do that. I was = purely reacting to David's suggestion to "not worry about lpage_infor for the time= being, until we actually do support larger pages". > > Is your suggestion around using guest_memfd ioctl() to also toggle > > memory attributes for the scenarios where guest_memfd instance doesn't > > have in-place memory conversion feature enabled? >=20 > Reading more into your response, I guess your suggestion is about > covering different usecases present today and new usecases which may > land in future, that rely on kvm_lpage_info for faster lookup. If so, > then it should be easy to modify guest_memfd ioctl to update > kvm_lpage_info as you suggested. Nah, I just missed/forgot that using a single guest_memfd for private and s= hared would naturally need to split the folio and thus this would Just Work.