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 23C56C3ABAC for ; Tue, 6 May 2025 05:29:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7A83B6B000A; Tue, 6 May 2025 01:29:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 755AE6B0082; Tue, 6 May 2025 01:29:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 61C636B0085; Tue, 6 May 2025 01:29:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 42B716B000A for ; Tue, 6 May 2025 01:29:06 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E2BCF141898 for ; Tue, 6 May 2025 05:29:06 +0000 (UTC) X-FDA: 83411354292.03.9679993 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by imf25.hostedemail.com (Postfix) with ESMTP id 0B84EA0006 for ; Tue, 6 May 2025 05:29:04 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=MxiRzdZK; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of vannapurve@google.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=vannapurve@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746509345; 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=8lKEB5k3HxIIDe0cms88dba//bFVC0zSsTglMVdhTdQ=; b=z3EWnO+QRXtkNo9cfUe8FDq4AV46dvyo2mrv/fWjGt2jPRdD/zlh90nPfnHbhvznB8rZrp MTJtjNy9cEu6QDUo6nC/Oq8AWCUTddhO6UAW26L4FsOPOsN5b6TxYVrk2ukGK60/yvhSvi 6e+vfPGpkIc6yaezPdvHOh9M4dA0p3M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746509345; a=rsa-sha256; cv=none; b=IXyVJAV4pdAofCgpMj4QXdX1b5fvCKaNL8XGa7NHhWbdpJp2Y5IZP4rPSKYXehghFpiLC2 x4CpEfw5mNuc7Jz+2nECAsKq6oAQDs5uVF5qIfNKX9GtURYl7oDiJ0fH7fc9lo7Ah3BHBZ GcFf/iTd9TdAAgFtN8JFBV87FoVyN2k= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=MxiRzdZK; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of vannapurve@google.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=vannapurve@google.com Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-22e39fbad5fso67015ad.1 for ; Mon, 05 May 2025 22:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1746509344; x=1747114144; 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=8lKEB5k3HxIIDe0cms88dba//bFVC0zSsTglMVdhTdQ=; b=MxiRzdZKn/kB/huUmqh69ewG+/IXEggAn9yXDdIHka13iMHiWithPoL/bmGlMKhHph NIt5sg1GiReYN5AMZ5RRLVvODPRwxhQYUTzCaqVXZsi8BChB//eLhBOXJtbmbjRSnU5x +q6zVKgCkZv0wdA13y/s4viB26zo98S5qm3JcXcV7L/ATuvmi61e5gSu2OeNAE2ujcrG 30MT0iIbc3XdnQDoYv8Plv8Mq0Gr2Kia8IJKaYqWK9BTbt/pa0Ma1JaeDk8E1X2bESu3 EupOiHC52ArKafjlHh1Ttnlp4ALBA4HhyvtYfWtGJ6CZwokVIww62WpRPa7jTXZlaz86 1yRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746509344; x=1747114144; 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=8lKEB5k3HxIIDe0cms88dba//bFVC0zSsTglMVdhTdQ=; b=Ift7GraFqHZTBEKgtBEuIb62w0UtfSB9hI8zxAv2ZpfGv3XHWNRWEsSp2wJFD3kaY3 jCs5BxbBrE5AAoT3uwSJXp0MOfteV3CXhaOkwftGnYA2NTiWxoQQszRJ/SyDWxbiRvhr +P0+mdQrcu3apdNsLnvcQ9Uod054Ip0xqWKgOB8v7kAMTzdYkGOYZo+wgSPUITjZUnWN S4VPjrKcqCsQOisQqAdgXUaQ84O3aSoe607MqY84mzSl9kPBUpupzx9qk1VJMtMe8TPE wWFDSxtWzohEkwqsUKW5ERm98DxOdFzzroR3NgWoUrgmtB+I2K53NTrDx1O4LSabTXvr LL+g== X-Forwarded-Encrypted: i=1; AJvYcCUjHO0EH8x6fqHZfkNfawSMddwxiRlqvnds/6woOJTFLtb4VISxFo4CgZ3PQDbRjBn8Fe+MS3So+Q==@kvack.org X-Gm-Message-State: AOJu0YwAOjjSl9ZtH28BlEMA8l1O+y5QBQcVt59rPB38WXI1DmOanhoi 6p7BxHkKvq3d+GzoSXSYvdUwBDrKWAcMjWYvW0SAsj0ohe6htnAnTmhIb2uBEenmOWDVDmC+s0k FC8H6YN6TgwgJ6X9BqRtXEJVLFjgUW7lT1z8Z X-Gm-Gg: ASbGncvX+y1VlZddo/cAuh50wHiPL8oJdIZRomES4iwRPe52qm2aae5F3xZh4MqlvX4 L+ZRhbZfDB+4toq2ss0LOtaatFbdRRPrjyR40H/oguhbzx9KD53qNz4Hir+ip+9wxZFfbzXc3sF yn19Nw918gnq9nhOESAVYj9FzBN9q52Q2Lvy3VH8k6MYrYyCGtok+p17g= X-Google-Smtp-Source: AGHT+IGwP1SKPwt/vtIJlYZ900Cxz2LT+AxXPcnHmyrXr5wchbo2E0xH9OpvxlPkZnYK2crcfarvY3+ODrHWYOxROP0= X-Received: by 2002:a17:903:4410:b0:215:aca2:dc04 with SMTP id d9443c01a7336-22e3508dfb7mr1649445ad.26.1746509343525; Mon, 05 May 2025 22:29:03 -0700 (PDT) MIME-Version: 1.0 References: <386c1169-8292-43d1-846b-c50cbdc1bc65@redhat.com> <7e32aabe-c170-4cfc-99aa-f257d2a69364@redhat.com> In-Reply-To: From: Vishal Annapurve Date: Mon, 5 May 2025 22:28:50 -0700 X-Gm-Features: ATxdqUGXwDZ11ffKoeTta9OzQcx_M0fYA3TqS1Q4kf5Xbu-qRP3DA_ZY9TBWlyw Message-ID: Subject: Re: [PATCH v8 06/13] KVM: x86: Generalize private fault lookups to guest_memfd fault lookups To: Sean Christopherson 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-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 0B84EA0006 X-Rspam-User: X-Stat-Signature: 3snnxkjhmx6zjpznkqnwpdp8xkfte6rx X-HE-Tag: 1746509344-155225 X-HE-Meta: U2FsdGVkX1/5fjAqt3h9uG434kAeWoq/damIXMnXitPN5MFhiJo0R/V2omVAnlmn1qhI1lt8pIje1wAPx3N2lJ3Ya/R7ubLwPk3pTe/ltBY2zo2QeEv1Vd+MfZ7Uq/SXV5Vvlt9Y6Mc0bgBf59s0/qV41OlrtaP+gpoHjVohYUjmx7Bh3pDjAht5Qfc77ZasP965i/G9CckgAq2IuG27YhY834G1ARV0Evcn//RwoivGvY2zGbWwG55mZsoCfHuAbCdbUZ/WH/TqnBubS9NOcoZMxWj9waRR35SSl5fFG3H0B4vPEerO2RY4dV57TwpqytUawZXCBTLEQL1+vv57DmNhyt1zIuhqbvCPtRHyu8z7PMDqFCmny/krVtd2MOGnb5gzZEzFZW+XSeKJMggmvOZtosTKIyKaMljOxqfx+9iSauVTMdHoylhF6PqHZiLEfHirb6n8+CP8AnJePmoI0OeLhAG95OPrU0Zf0Vk8F8BQc0dPlEdzqOD9YNijKwZlVGR1XYLYhW6WzrfPvrVetYJt9oOy7it3M3+1wOR5lSw1FyRKokSr4soUWYX+uJF+nsW21APBh8jGAEZ3pFXe3bRgEwSmEQh/R54SMi2I1aC8lVY4+fyAMkvy0i4XpZZuH0MSWX3CcXPXZ+/35Ir5iFMd8H5LAsDDYauJyG8C4QisEhipFbRC53PRJD8L4hqZ07RfUNljjvpzx8oBJCtAu2P5h12txVRBC+oEW47i0T5ibLmVSntVpXLD+oKKj/5i+BO9FRI8035CXcyL90FS/9V3Vv8Oc/0nXeouJl86cRsd9QsBV3+A+qpXTemL9CLUhzEd2JzIIyoygRSXXATEjBiSG2LSxacLP3wlhirdcpQ+cgd0w8aK58Q3imy68V/6pEwNYgEfmrW9q3RstAvILy2V5VrmKBBIcD893kutX3V2MVzp4moDHEETBRZSqtrjYRcmJ9K1iJfzm36XOfb ds3svQ/O Aif3sRmXCnwkGdek8FxZKK4QgjUGG5OHeZ8wWOjbZ+Vzj5KKXFwW56c0VXOYgMKoiNVWc4L9T37ZaEEXULX3l7s3TU58Q8UvKpwKdKTHZ3Bzi651eSq4LeNtwbbmCQdMdBDmjOusFaZUeSPZAnVwi+wkPKguw5+gSM8V18lpXot35fG3hZlWKMxN+8e8t0wzMmfJQ2Dl25c3S4dTW6766+alHs113Hs39OTlB08cG7TYcvjsTfXLEtyZVF76CDarx86X4ifs+ysmqHJeAkX4zWSux1ErV67a23eUNXudvgUqPjVskS1xffBhH7uxC76ZKkh4ZW44914oVfzkM8PKIh76T4g== 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 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 actually= do > > > support larger pages. > > > > I don't want to completely punt on this, because if it gets messy, then= I want > > to know now and have a solution in hand, not find out N months from now= . > > > > 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 the = 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 process= the > > slots that are bound to it. I.e. why not update KVM_LPAGE_MIXED_FLAG f= rom 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. > > 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? 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.