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 71A1FC3ABC9 for ; Fri, 9 May 2025 22:38:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E33926B0104; Fri, 9 May 2025 18:38:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E09AB6B0105; Fri, 9 May 2025 18:38:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CAB016B0106; Fri, 9 May 2025 18:38:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id ACB1F6B0104 for ; Fri, 9 May 2025 18:38:55 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 03A6B1CE6DA for ; Fri, 9 May 2025 22:38:56 +0000 (UTC) X-FDA: 83424835914.19.EA2D0DE Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) by imf09.hostedemail.com (Postfix) with ESMTP id 1ABD114000E for ; Fri, 9 May 2025 22:38:54 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=4A7isiMD; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of jthoughton@google.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=jthoughton@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746830335; a=rsa-sha256; cv=none; b=Yag0tni5BGfXjshykMWpZjpZxU/FrdntzHTGrqrt3RlUgkbctAG5CP/3rwvUK2wv521z1/ 8WfNETutHh8AVl177dCRQQNtJl1ccyeF2/LV3jZWHPLbD++uzD5FF6eOmNEeVa0BuUszJc 4OUx+JOC/L0C8pMWy51mOpIyoka6mp4= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=4A7isiMD; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of jthoughton@google.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=jthoughton@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746830335; 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=4y+7YrkNmYTMpHr+hnhsBX+FluOGpdkroormS9kd3y0=; b=yTjGQOGm42iqlOd4mzk4cfRp4EdDlXyfmQmyCupQ8vf/GKIEAaPkCrBxUdP7PBhvgzxINN 3/fIlqLU8/LpxDDDURtbUbLjpCdEiNqNHf/SnQYFsYwQPgPXrtuKwZWkAgRP2bZ9MTvLIg NKrqWe8lgCWEN9oSn3wMwq7NHiaTW9w= Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-7086dcab64bso26450577b3.1 for ; Fri, 09 May 2025 15:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1746830334; x=1747435134; 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=4y+7YrkNmYTMpHr+hnhsBX+FluOGpdkroormS9kd3y0=; b=4A7isiMDns4EpBbWvyFKVq/gl2fchqhzSwzizOaRSNsjSvkXjwcjjdxfWWjCEWJP49 vfY9pOE1sCnLqTZO2xhGdiV2Xx0Bs/2Xwf0GR6EOu0zJ3p6XO1KUWgj242RakfwuV053 UMCy5/FPWOSUCozP0dZQH1NFB8FTwwL4jcssHDb56kPoFkEyJ39TYK2Y0hN72nQ7vc5s avqasgLkhGkAPzabPm0daBco2S9fFWYzb8mbYt0SfoQ3TV0hR0+N7UK/NkhS/ytvuZGE MmFNqHFtpISd6BJ5hQxt5oyFRl5liOXRm/jzTtpYgiSTmVUPt+5Nmz2VWXiu/rl2iOVB vVRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746830334; x=1747435134; 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=4y+7YrkNmYTMpHr+hnhsBX+FluOGpdkroormS9kd3y0=; b=bWz4Csq1ewbw2DaHijO+iI8y3fueJ9Ko8ZGXHEIJ85SzpnkYQcW52Cx9W8gnfpSaUj Oxbi0HBNr0X1MdxcEEuganMboNGuhPxIXde8xQ7zhTarTD1HAd8cNkj/1/TPXjn3aI8q s6OXPK1wwsmPs49Xl3ejd8+RbxU66lrU8WQFEKlEKgGxk364bl76EJeUmDriRc6556ac 6F4/7mTIsImHNOcB9vJ0CZ4uyImubcgIIZmsyun2qcSiHNo0dmRCZHqTHqTVVEdUo9b6 pGHl8JoeTg+Aw01XnBVuWJkP/0MwewobsKyGyj/hxm8eiLoxNjZzYovIrU/4C0klVFcS TIPA== X-Forwarded-Encrypted: i=1; AJvYcCUYHrWnzrwROMlaBPU3YmUNU4LRONd9bSjSCXdOTv2QmaR32Uv20/EnKAsSslH/K3DVsncpw2PyHg==@kvack.org X-Gm-Message-State: AOJu0Yzl0leP8PXDpZppxeZoQ1/psLUtgmrbxtoAir/pG9lk1a57Dwcg fW7veXlbJMw3+iz6dH5x2iNfI2elEhiEiN8eisuo7m6dQLtUlEZRdIY9iQBzT119APzvCk8YjWO OsWDrB6I6cvYZf3rCKu2JkjU5H+5GzPSBC4CA X-Gm-Gg: ASbGncvnB6LAIoEEzrn/Q2FKdXG9+tbJTd3qNOS/H0YQpz3oKVgBQpBSTv1CrJ8GjwL Fm6ftzF3Sr8MgWeA1JC0vD8mbVRqlvY1AfzlYo67Za/iL9Vc1Cn2a9jDql2kRHcpRR/IXa3vYcz L1lBvsg1dR1g5IIOMJ4Sft30lyTLAJiuS8dpa7rN0vnX9pn2FSYwVBSx0e4Va0KgE= X-Google-Smtp-Source: AGHT+IEdJ+t/M16J4dyjgQQaZBcaPjjKUhl0VsQtk+UZnkR2Q/ptZ5TFyDnjP/nWec8PjOqDBhuDWCDx/3z7sNn8daQ= X-Received: by 2002:a05:690c:498e:b0:707:48a7:ea6a with SMTP id 00721157ae682-70a3fa4037emr77537247b3.19.1746830333843; Fri, 09 May 2025 15:38:53 -0700 (PDT) MIME-Version: 1.0 References: <386c1169-8292-43d1-846b-c50cbdc1bc65@redhat.com> <7e32aabe-c170-4cfc-99aa-f257d2a69364@redhat.com> <39ea3946-6683-462e-af5d-fe7d28ab7d00@redhat.com> In-Reply-To: From: James Houghton Date: Fri, 9 May 2025 15:38:17 -0700 X-Gm-Features: AX0GCFuLEYUHA0d2HeMJJiPSjcin0qtvtKfgi2kmBbW_YclH7-KTCKoitgoaUSw Message-ID: Subject: Re: [PATCH v8 06/13] KVM: x86: Generalize private fault lookups to guest_memfd fault lookups To: David Hildenbrand Cc: Ackerley Tng , Sean Christopherson , Vishal Annapurve , 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, peterx@redhat.com, pankaj.gupta@amd.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 1ABD114000E X-Stat-Signature: ocr6n6neh1gk6r4sqqqhtxo1wqs6wj3h X-Rspam-User: X-HE-Tag: 1746830334-58647 X-HE-Meta: U2FsdGVkX1+1a+i4SsEEOmma4O04Sun9QrmdcYxqnHVD+2CN3SIIV7NBzK3v9WCJ2L29g/SHyROH7LcaEC2gz1C/lr2Owaba6u0iB7innOB27EdFY/9Z2Bq/qW8n//nNZvIfqNipno5ggGR06+HGdKX12JpMBdKK/CRpH/Pltla4t9VAuTRHtb9r8ONkdI5f8ZMlAIT8eMjaCo/N6PwWkXp3JKgUgAZ0p1HxJyxi9tAZhtFClcGnRaGFnFs8Nv7yqF0e9syJUli6XCXkUDmbhNnDdH+LsIbHlzld4KEUlTii3gbj2KqxDo/xZ1nwIavhB1bqIDqk7/0HBbRcCkJe8ZnUVfgr1Pe8/KWSYXImK4LTVUqlcN37wlYDQ36/IyV18p1ThxoM/7ZGMaWiBq5Zkpn/vniOtqQkT4ajI/XflEucUVrrbjukHguAl1xywNCUO+iLc8jqzvigSFyI/hHHt209JXRy1A/E0viVZCq9WnUCfkTxXbvtudQgvwO6AQf+gP9erfcOt/qu9helFrsU7fFCf0DoZleeoyhba2BYyxYSwht6hELdiLj/ij+zqhBP+7X3GrBM3Oi74+6lmJwLZf55STxaCb6su0wSkCvbLQkfVCOAA/lAi1367hIyKxKhG0G0yulN1d/Fy2pmvVxAxKD2unIeEx0QQZTJ/kCFDC94GrkQcCIINhf/Y/EcyyxHZAppzyK/XuXhvIhiBmUdixpfruAkxxViQVVbhxA+HwEuNfrkV1ZDwCNcqWFSHW/mgo1xtxXdJpzlrgCEAooObtr/Gj/7GC+wEtRh1JXIkKP5T85bkaGvHptc/gamBek/aXGar2kxh5DbICPPnRMoJUFeU1pv5cPyvd4Nk5aahMVEFoy1+7MEnMbY5tfL2MmKCGcD4ZS2rO8JXY/xjsJYv61JZ24G14tWB2b3cqwTLp4aFvq3bo7egmoaNJ8WM4pBthVAEjiNrxTvOV8vDTq ikf9iHc+ yfn7PRt/6r21T9axd1KJUZ5H6ihVDxQT5Q9vWS+ZyhJtPz1tBg+A0QOwZ7vjhfPQsn878DMxmHEzY3i6IxZ77yG+nnVFiyrw3XoifwMpUACrsHFPPE76dnhTPt4V89x43RHUbap1V6Mz1ZQxNZssF8NRiWyVOKct5+4CoUjgCKNt1DOebWeBxA6lAHCuzuLi1G5B3GOLdYpmxgDgKZTKNVNJMcewGsoeSCibs8kYFrOPXAHfqvf9nYcWPskXZiGLIIgA3EUfhwDzvrTaGdF7lmsdrTqLxWaCrPNmh0n+IATxS1IS2R44KJ7hGwyMyOubauNxnn7eX3C53UTyaE/Q0EYT77zY/6xDmssBNNjWZbdBMhnM= 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 Fri, May 9, 2025 at 3:29=E2=80=AFPM David Hildenbrand = wrote: > > On 09.05.25 23:04, James Houghton wrote: > > On Tue, May 6, 2025 at 1:47=E2=80=AFPM Ackerley Tng wrote: > >> From here [1], these changes will make it to v9 > >> > >> + kvm_max_private_mapping_level renaming to kvm_max_gmem_mapping_level > >> + kvm_mmu_faultin_pfn_private renaming to kvm_mmu_faultin_pfn_gmem > >> > >>> Only kvm_mmu_hugepage_adjust() must be taught to not rely on > >>> fault->is_private. > >>> > >> > >> I think fault->is_private should contribute to determining the max > >> mapping level. > >> > >> By the time kvm_mmu_hugepage_adjust() is called, > >> > >> * For Coco VMs using guest_memfd only for private memory, > >> * fault->is_private would have been checked to align with > >> kvm->mem_attr_array, so > >> * For Coco VMs using guest_memfd for both private/shared memory, > >> * fault->is_private would have been checked to align with > >> guest_memfd's shareability > >> * For non-Coco VMs using guest_memfd > >> * fault->is_private would be false > > > > I'm not sure exactly which thread to respond to, but it seems like the > > idea now is to have a *VM* flag determine if shared faults use gmem or > > use the user mappings. It seems more natural for that to be a property > > of the memslot / a *memslot* flag. > > I think that's exactly what we discussed in the last meetings. The > guest_memfd flag essentially defines that. > > So it's not strictly a memslot flag but rather a guest_memfd flag, and > the memslot is configured with that guest_memfd, inheriting that flag. > > There might be a VM capability, whether it supports creation of these > new guest_memfds (iow, guest_memfd understands the new flag). Oh yeah, I remember now, thanks for clearing that up for me. And I can see it in the notes from last week's guest_memfd meeting. :)