From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Christopherson Date: Tue, 30 Jul 2024 15:35:18 -0700 Subject: [PATCH v12 00/84] KVM: Stop grabbing references to PFNMAP'd pages In-Reply-To: <419ea6ce-83ca-413e-936c-1935e2c51497@redhat.com> References: <20240726235234.228822-1-seanjc@google.com> <419ea6ce-83ca-413e-936c-1935e2c51497@redhat.com> Message-ID: List-Id: To: kvm-riscv@lists.infradead.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, Jul 30, 2024, Paolo Bonzini wrote: > An interesting evolution of the API could be to pass a struct kvm_follow_pfn > pointer to {,__}kvm_faultin_pfn() and __gfn_to_page() (the "constructors"); > and on the other side to kvm_release_faultin_page() and > kvm_release_page_*(). The struct kvm_follow_pfn could be embedded in the > (x86) kvm_page_fault and (generic) kvm_host_map structs. But certainly not > as part of this already huge work. For kvm_faultin_pfn(), my hope/dream is to make kvm_page_fault a common struct, with an arch member (a la kvm_vcpu), and get to something like: static int arch_page_fault_handler(...) { struct kvm_page_fault fault = { , .arch.xxx = , }; r = kvm_faultin_pfn(); ... } In theory, that would allow moving the kvm->mmu_invalidate_seq handling, memslot lookup, etc. into kvm_faultin_pfn(), or maybe another helper that is invoked to setup the fault structure. I.e. it would give us a way to drive convergence for at least some of the fault handling logic, without having to tackle gory arch details, at least not right away. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 30A7238B for ; Tue, 30 Jul 2024 22:35:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722378922; cv=none; b=LfXDba6KVPCO1/wtFadRq07jkt9JEdxyX9Iii2XqUOIAq/E9vG0y8ivtyJc3+yW6SXwx/Jj+5GFWahTYXL6b9GaiiPJtlh+dfae4IyFbZD1xyhUrhLejR2YYhXqzh5Y8u5p+z1HL9gxkZhWX8DpiOxAeRNEgq60YWNxNUvBUUu8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722378922; c=relaxed/simple; bh=YFDCChsqaB4UhHP0/2HzjxvaMXC55WBTMkh7IBQDDtE=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=hLnruuqXmgcT+lCthwUoJzN6RDzvDpBZwGDcRExiovUOWhNEEnsFppUNOy5wlPjKwvk1CJlh7z7bN+hfPss/NUhOEaNgfngfmaptaRsLcrKkPay1TdocOuWy/Umfwc7KLL0+NzgZwe8c8txAhd8RNooYtYzHRerflY2mGA7JXJU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=dyR82lnw; arc=none smtp.client-ip=209.85.210.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="dyR82lnw" Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-70d188c9cabso4144936b3a.0 for ; Tue, 30 Jul 2024 15:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722378920; x=1722983720; darn=lists.linux.dev; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=eSOwPlC4K/K4c1NtKrHXJlP1TgjanOwgNCfxP6XzMYQ=; b=dyR82lnwmdLl0WcLqcAxWHGW51KIKMIAMkJUUH3tL/oMTnv35dOTKC4TyYQqEOWP9t fVgM/5NjUycQkPThxTgBDuzLS9izlsIWj5bnV7TIHEUnfPkH37KaAn7qJ3ufiksq/7kh /lmFPrXR/8aJ0xClwW07R4Zmm/JKtrT5pUQkj4ScVR4VOxVaj6cHfR+ejYtsvo7hjWXA 0tYeXKU/wiFpMHpWms+EYYszMQt47mHeUnkzInEMTtBrdfOGQjGQjj80BZiln2t1rdlC LHGDinBLzUpFh1/Gb+v1HmwKo+wnKzY4ci6/1QQhyHywozRcIBLIaNeQIrkddermhi3P qQ1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722378920; x=1722983720; h=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=eSOwPlC4K/K4c1NtKrHXJlP1TgjanOwgNCfxP6XzMYQ=; b=A2KfnFYglQCJzMrQ43fn64UcZ/V0fbyU97tCjpQlmOO0SDDmLMBB94JV4wBDJ+v09y k8Fprg9hGcP9GGnvV/FrzC8ggHhlZaOni+lDRIybqUZW6rGr90NpBHqa0gBVlxiyzLlm 5fVKbQLnej30+RarDAR6+CwzNDzaLOWelIASBzfYOvPUwsACyuf4AWKotdSVl2uXkTgd 7L2X7dlY7kmz0anXSPG90IuHEQHUFyb08PLulPUvbd72V0hged3osVJw1645BvIbSF/q 22u1BXxis3zO1y1gXKIEsLTCZ8Q0zIpntZyASqqIduPeQmlMky1cf55DUyWprSGWund7 IXGg== X-Forwarded-Encrypted: i=1; AJvYcCXAW2ArRAN86A+Enk0W7qsBjxFqvn1hGDDAji/7CCj+JSpE3mL4T58abW1/OXFG8EJEXa6Dse7MnLIIy0Lm/8qb0gQe+sNF X-Gm-Message-State: AOJu0YzhCbLxaiLd/lY3fQ2p97xpYvUh7vbXgLEuuxmxdK4p2V+iX1i5 udLZ0roh9q8ARPxXdAs8h7+hciHiP7iazd2cCnJ/jq/zmywadExqGWpw6xR8MmswD6qZm5ZI10V tLg== X-Google-Smtp-Source: AGHT+IFhvXMAoVFBOUzUOOlo2Rzlu+lOmmXT/AMKduASO9OrwvfaDw5U6qKsr5Vo6lwrA4+Cjt72+QiZt8Y= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6a00:91c7:b0:710:4d08:e41f with SMTP id d2e1a72fcca58-7104d08e48amr716b3a.4.1722378920090; Tue, 30 Jul 2024 15:35:20 -0700 (PDT) Date: Tue, 30 Jul 2024 15:35:18 -0700 In-Reply-To: <419ea6ce-83ca-413e-936c-1935e2c51497@redhat.com> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20240726235234.228822-1-seanjc@google.com> <419ea6ce-83ca-413e-936c-1935e2c51497@redhat.com> Message-ID: Subject: Re: [PATCH v12 00/84] KVM: Stop grabbing references to PFNMAP'd pages From: Sean Christopherson To: Paolo Bonzini Cc: Marc Zyngier , Oliver Upton , Tianrui Zhao , Bibo Mao , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, David Matlack , David Stevens Content-Type: text/plain; charset="us-ascii" On Tue, Jul 30, 2024, Paolo Bonzini wrote: > An interesting evolution of the API could be to pass a struct kvm_follow_pfn > pointer to {,__}kvm_faultin_pfn() and __gfn_to_page() (the "constructors"); > and on the other side to kvm_release_faultin_page() and > kvm_release_page_*(). The struct kvm_follow_pfn could be embedded in the > (x86) kvm_page_fault and (generic) kvm_host_map structs. But certainly not > as part of this already huge work. For kvm_faultin_pfn(), my hope/dream is to make kvm_page_fault a common struct, with an arch member (a la kvm_vcpu), and get to something like: static int arch_page_fault_handler(...) { struct kvm_page_fault fault = { , .arch.xxx = , }; r = kvm_faultin_pfn(); ... } In theory, that would allow moving the kvm->mmu_invalidate_seq handling, memslot lookup, etc. into kvm_faultin_pfn(), or maybe another helper that is invoked to setup the fault structure. I.e. it would give us a way to drive convergence for at least some of the fault handling logic, without having to tackle gory arch details, at least not right away. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 37972C3DA49 for ; Tue, 30 Jul 2024 22:35:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:Message-ID: References:Mime-Version:In-Reply-To:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=Ynuj8rd+5LWGQguivpJywA9gYBNF+U4dY5xt9dOpvaQ=; b=Lers+B2mgAMng/n1sbwFoE3Nk9 S0fJkWXJFdiPPCdxHdaLYKd4ZnHbeb6ooJGYZwW9yJbdHL/+2FBXby/fdUoUJlisqUHl2YhAo125q P1MY8fKU5SXu+gFIEdguLeby8iCeQmGnGyi5EqoNS8jSgsmfkfcHwvPNUEqq1HnghcNH/RPRDMFLs DsemA/HcESA2Ji5vgG4zKg4lfyTsimQQQGoKYIDLWWbGa1L1M1Vm+cwC25RDj/X0N0p1XvPGKydOc jwfvBuskkejRKC4v3im7gbRGBy25MY5/csCA3LAgVW2Cs4T3jPUKKK/WLTIdoT0ioJiIVrjoTVWIN pHwiDYqg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sYvRe-0000000Gf5C-3U62; Tue, 30 Jul 2024 22:35:50 +0000 Received: from mail-pf1-x449.google.com ([2607:f8b0:4864:20::449]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sYvRC-0000000GexV-0VFp for linux-riscv@lists.infradead.org; Tue, 30 Jul 2024 22:35:23 +0000 Received: by mail-pf1-x449.google.com with SMTP id d2e1a72fcca58-710415c77f8so1529866b3a.2 for ; Tue, 30 Jul 2024 15:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722378920; x=1722983720; darn=lists.infradead.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=eSOwPlC4K/K4c1NtKrHXJlP1TgjanOwgNCfxP6XzMYQ=; b=Elm1aRSg2mgRtxcduDJNtMj2zrDYJPC/VhiZqtN24Lqg3GINzp3ftmZdzBbKw0ZCJv HuphzahE5dIg3elHmyeml/MfCzsg+zPPtrFf91kR2BWvbsyFYb+L2x2J015Vb30AYUkO 9ofOrbIRas0mP/Hj87wRU2uX/92+KneDusDTMTpNb/8cMwJiwUO2jgjmsQLPXOhLFNVY wN2lGGR9S+Ib0lqu3EhABk674snU4L1yTcAE3UK9Keq6fekkD/p1o3Guq5U6W4nNVMhN V7uJa3XmGzI8SMCApwTGWlmjnZGAbyZbuBa4SYUFFuKYFuhs16TViESClRvTXiJSTvgA i/YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722378920; x=1722983720; h=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=eSOwPlC4K/K4c1NtKrHXJlP1TgjanOwgNCfxP6XzMYQ=; b=KerCO6BKgEUS/8PXDSBzwjJbO/iz4OWSRIfBu7BuX6hE2xQnvapfQw1h3iRXzsleji lPWjOxFtSYgVcMNhO2nmlJVaiVeMd4SEfNzuJaI2s8P/VpuFSpt9knrM4gVei00B/Zrs 7Vg3fqS/lBBVNVuGGAFQ7MLRSQtrsAcqPJKIoKoa93f8qtdkYTTo8G0s3tOFVvoM5/32 mLJgp1ZgKwNbIykDDV2gtzuvBzcVAQcXeArEwGfmxRz4h60MzXYmN1sI/93FSLLu/L33 MWxx+tJmOZhOXMHsNzrwKRIllv5wZWl7VKueKZ+Bj8Y2bJpbtv3rPYMzzKY6ZRkUtfgZ PuJQ== X-Forwarded-Encrypted: i=1; AJvYcCUqrLEIXEdRqeyX/DrZPOUvy/y7ajn7Ktgw3enrAKRHPRh9CuNl7XMS1NdERJu5VeldY1QR/Njz2o4dwgimIMmxaRstJA+LaSgzrlJNPHu3 X-Gm-Message-State: AOJu0YwbZf6AJAEUUXGUEnEVGEJECFVPtGKiLdi5gpSZWCZ0P0EaKzgw HLApROlWo/BULuNxegmmuJe+vuUisdYiybfJ/UiA5YiU/tymuBYAwGu242tbDHETXd7AS+0jsqz etA== X-Google-Smtp-Source: AGHT+IFhvXMAoVFBOUzUOOlo2Rzlu+lOmmXT/AMKduASO9OrwvfaDw5U6qKsr5Vo6lwrA4+Cjt72+QiZt8Y= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6a00:91c7:b0:710:4d08:e41f with SMTP id d2e1a72fcca58-7104d08e48amr716b3a.4.1722378920090; Tue, 30 Jul 2024 15:35:20 -0700 (PDT) Date: Tue, 30 Jul 2024 15:35:18 -0700 In-Reply-To: <419ea6ce-83ca-413e-936c-1935e2c51497@redhat.com> Mime-Version: 1.0 References: <20240726235234.228822-1-seanjc@google.com> <419ea6ce-83ca-413e-936c-1935e2c51497@redhat.com> Message-ID: Subject: Re: [PATCH v12 00/84] KVM: Stop grabbing references to PFNMAP'd pages From: Sean Christopherson To: Paolo Bonzini Cc: Marc Zyngier , Oliver Upton , Tianrui Zhao , Bibo Mao , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, David Matlack , David Stevens X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240730_153522_165121_955A61B4 X-CRM114-Status: GOOD ( 10.94 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Tue, Jul 30, 2024, Paolo Bonzini wrote: > An interesting evolution of the API could be to pass a struct kvm_follow_pfn > pointer to {,__}kvm_faultin_pfn() and __gfn_to_page() (the "constructors"); > and on the other side to kvm_release_faultin_page() and > kvm_release_page_*(). The struct kvm_follow_pfn could be embedded in the > (x86) kvm_page_fault and (generic) kvm_host_map structs. But certainly not > as part of this already huge work. For kvm_faultin_pfn(), my hope/dream is to make kvm_page_fault a common struct, with an arch member (a la kvm_vcpu), and get to something like: static int arch_page_fault_handler(...) { struct kvm_page_fault fault = { , .arch.xxx = , }; r = kvm_faultin_pfn(); ... } In theory, that would allow moving the kvm->mmu_invalidate_seq handling, memslot lookup, etc. into kvm_faultin_pfn(), or maybe another helper that is invoked to setup the fault structure. I.e. it would give us a way to drive convergence for at least some of the fault handling logic, without having to tackle gory arch details, at least not right away. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 393E6C3DA7F for ; Tue, 30 Jul 2024 22:36:08 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=kmM7Tzmb; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4WYVSQ43x6z3dBX for ; Wed, 31 Jul 2024 08:36:06 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=kmM7Tzmb; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=flex--seanjc.bounces.google.com (client-ip=2607:f8b0:4864:20::449; helo=mail-pf1-x449.google.com; envelope-from=3qgqpzgykdf8pb7kg9dlldib.9ljifkrumm9-absifpqp.lwi78p.lod@flex--seanjc.bounces.google.com; receiver=lists.ozlabs.org) Received: from mail-pf1-x449.google.com (mail-pf1-x449.google.com [IPv6:2607:f8b0:4864:20::449]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4WYVRf4Mqyz3cVR for ; Wed, 31 Jul 2024 08:35:25 +1000 (AEST) Received: by mail-pf1-x449.google.com with SMTP id d2e1a72fcca58-710415c77f8so1529870b3a.2 for ; Tue, 30 Jul 2024 15:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722378921; x=1722983721; darn=lists.ozlabs.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=eSOwPlC4K/K4c1NtKrHXJlP1TgjanOwgNCfxP6XzMYQ=; b=kmM7TzmbEhYff2gm16QukWc6XgqxUlj2ahiLh9D57AtIvQEV27IvL6KFKxzpAxmabi 75yas5mrvw6N4R5d4mkw9nX6kiyuiFsXKDWmP+/TWIHzj9FK3tceTM2QIVQN8pv3gqTW yDRY0GOX+7rjwS4xU0Gi393YWXQrobjPL2BFSbCZ8KhWt6Ki4J11ShkXRc4Wt1y+ZJpj oVLqJ6vzwRdBCOxF3FkTgaiEOHCovc6aKRa58ohLHaUP55zgd4inqVZSE+ydbw6mImV0 OgudfgIEDCh36RnsnWOa9K/3ciQ99fjErfrpXbq4z/BMvEbfo/VHfPyGoeSw5D9vfYyV 6a3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722378921; x=1722983721; h=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=eSOwPlC4K/K4c1NtKrHXJlP1TgjanOwgNCfxP6XzMYQ=; b=DAL8KFximtR4KeJbvpwhsqGJDM5KS1YpXsfvP1Acd+u5H0iry9PWF29nlSoiJVs4iY TlSk50ndFS8tqFAh56XrMDL1Tm+Fy8RWXpp1WfrZtlHDUPMlMK4LPl6Cjx/VDXadfdpH ZznEySwa4d2+2427dQUpdrhwsEFMtukpCD05WJfm4JGyO7R2jLhLd/kZOL5JiIbRRxQs juIIiibLtZFIkt6iqF+YTmvvX0ZHVsmoBh1mynQN4myE2CAIg0Ew+C9cwrZ95KeWSbbV cjY7pzm9L1Blk/xsFeAsSIowh0yUnj4WzxPZ04cuAnlvtQfY87iaevuly2OTHPORy/uW P/mg== X-Forwarded-Encrypted: i=1; AJvYcCUdXfDghUwYiNDYv+UxxgvDDyGE5GZeHcMLmbrE+pMUd9Mz19cA2LiYn5COesF3PdSidML9+q7hgnoZaeJFLBYql8SMZIKH7ucFSZ5adg== X-Gm-Message-State: AOJu0YwbyLXSuOozaSJ9vasC8JmV1l+M1qpkFqJuCiJQ5+vjaFWylJX2 ZL1H3elylVp1qoR3kcNRNCgHv5ddzyLNXmkgckeRO9zt7m1MsiYF5iz6zBadtJZljx3WZ2CwnDQ ++Q== X-Google-Smtp-Source: AGHT+IFhvXMAoVFBOUzUOOlo2Rzlu+lOmmXT/AMKduASO9OrwvfaDw5U6qKsr5Vo6lwrA4+Cjt72+QiZt8Y= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6a00:91c7:b0:710:4d08:e41f with SMTP id d2e1a72fcca58-7104d08e48amr716b3a.4.1722378920090; Tue, 30 Jul 2024 15:35:20 -0700 (PDT) Date: Tue, 30 Jul 2024 15:35:18 -0700 In-Reply-To: <419ea6ce-83ca-413e-936c-1935e2c51497@redhat.com> Mime-Version: 1.0 References: <20240726235234.228822-1-seanjc@google.com> <419ea6ce-83ca-413e-936c-1935e2c51497@redhat.com> Message-ID: Subject: Re: [PATCH v12 00/84] KVM: Stop grabbing references to PFNMAP'd pages From: Sean Christopherson To: Paolo Bonzini Content-Type: text/plain; charset="us-ascii" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, David Matlack , linux-riscv@lists.infradead.org, Claudio Imbrenda , Marc Zyngier , Janosch Frank , Huacai Chen , Christian Borntraeger , Albert Ou , Bibo Mao , loongarch@lists.linux.dev, Paul Walmsley , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, Oliver Upton , Palmer Dabbelt , David Stevens , kvm-riscv@lists.infradead.org, Anup Patel , Tianrui Zhao , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tue, Jul 30, 2024, Paolo Bonzini wrote: > An interesting evolution of the API could be to pass a struct kvm_follow_pfn > pointer to {,__}kvm_faultin_pfn() and __gfn_to_page() (the "constructors"); > and on the other side to kvm_release_faultin_page() and > kvm_release_page_*(). The struct kvm_follow_pfn could be embedded in the > (x86) kvm_page_fault and (generic) kvm_host_map structs. But certainly not > as part of this already huge work. For kvm_faultin_pfn(), my hope/dream is to make kvm_page_fault a common struct, with an arch member (a la kvm_vcpu), and get to something like: static int arch_page_fault_handler(...) { struct kvm_page_fault fault = { , .arch.xxx = , }; r = kvm_faultin_pfn(); ... } In theory, that would allow moving the kvm->mmu_invalidate_seq handling, memslot lookup, etc. into kvm_faultin_pfn(), or maybe another helper that is invoked to setup the fault structure. I.e. it would give us a way to drive convergence for at least some of the fault handling logic, without having to tackle gory arch details, at least not right away.