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 31DC6C02193 for ; Tue, 4 Feb 2025 21:18:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 962D66B007B; Tue, 4 Feb 2025 16:18:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9135F6B0082; Tue, 4 Feb 2025 16:18:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 800FA6B0083; Tue, 4 Feb 2025 16:18:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 635A06B007B for ; Tue, 4 Feb 2025 16:18:45 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id CB4C5A0200 for ; Tue, 4 Feb 2025 21:18:44 +0000 (UTC) X-FDA: 83083526568.01.98FA391 Received: from mail.marcansoft.com (marcansoft.com [212.63.210.85]) by imf16.hostedemail.com (Postfix) with ESMTP id B1F90180003 for ; Tue, 4 Feb 2025 21:18:42 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=asahilina.net header.s=default header.b=VShY9U8B; spf=pass (imf16.hostedemail.com: domain of lina@asahilina.net designates 212.63.210.85 as permitted sender) smtp.mailfrom=lina@asahilina.net; dmarc=pass (policy=quarantine) header.from=asahilina.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738703923; 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=AUSU93iGu3kKq2J5Bsj9OwNGMnyf9Xbvq3axBAIZAi0=; b=6VU+tZ3K7fA80IoLRaY6OOhyaaXLEotyF0cTJfQwzOYUiDVDyIDJiUBYnH9zKoaRbgDyCx 4slY5LmMYsfy5E0hhtB4HSwWKpRMt7tX9ED/0ax4WqyI/m7o7JxU7Tkg/pvVGDl0uAJqIz rsHZ6ed69QjU5E7IOlPed8oxzUNBbww= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=asahilina.net header.s=default header.b=VShY9U8B; spf=pass (imf16.hostedemail.com: domain of lina@asahilina.net designates 212.63.210.85 as permitted sender) smtp.mailfrom=lina@asahilina.net; dmarc=pass (policy=quarantine) header.from=asahilina.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738703923; a=rsa-sha256; cv=none; b=FmGh/uXEnziFQJv6g3cUnhmRt/dAdruGZXO4E08CxscxYsB8A9PKo81UVKbqvjPCZ6tIUl vJZQArc4iIEhBlWzgZSHFFHsGiI5QVctoMfwF21Cm3bcfROxpL17z+WxtdknyJLhHMwOxh my0Fkb9UB7qxEY7w+rThgFBJ75j1bPo= Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: lina@asahilina.net) by mail.marcansoft.com (Postfix) with ESMTPSA id 157A243321; Tue, 4 Feb 2025 21:18:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=asahilina.net; s=default; t=1738703920; bh=VfsLJGZBTaWPp/7dFr8cYv5uWLkZRbn9Nqa4s7PZ7Kg=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=VShY9U8BYjAWJERpxnFG57enS9OV5Ua6HOQJ5bWQyzJU7y1o5BeNhoLQOjt4T6F31 ySpglPhH0pMM5TF3j+sbo1H8CS9rRDUu/mv1wrZ65uhVbsY7fodlNTohTVj+0xDHF+ GAAVq6q3RsTXn2Dgat1jrcQQJgllQEECzKcLAAiAItqgjpktGk6g9ap9R77JE2w0pc UDBTFE0O16E822vzc/vsO5AIhLvP52CuMShTOIJtVKK0O7uFPLNLDBPJG0bvhOEctB QDQOr34u0/12knjU93FSdp9aB3W47Pi2zeQWphvsFtNlZ1Qx7W3GcAaHWO2E//Q8mu FIrc0Ay7kO7sA== Message-ID: Date: Wed, 5 Feb 2025 06:18:37 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/6] rust: page: Support borrowing `struct page` and physaddr conversion To: David Hildenbrand , Jason Gunthorpe Cc: Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Jann Horn , Matthew Wilcox , Paolo Bonzini , Danilo Krummrich , Wedson Almeida Filho , Valentin Obst , Andrew Morton , linux-mm@kvack.org, airlied@redhat.com, Abdiel Janulgue , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, asahi@lists.linux.dev References: <20250202-rust-page-v1-0-e3170d7fe55e@asahilina.net> <1eaf66ba-b2d3-448f-938b-913f17ca98a4@redhat.com> <20250204183933.GJ2296753@ziepe.ca> <1d379007-97c3-4bb9-93da-1a828f955fc4@redhat.com> <20250204202656.GL2296753@ziepe.ca> <08ce9562-9ded-4d95-a495-b60f90d75490@redhat.com> Content-Language: en-US From: Asahi Lina In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: B1F90180003 X-Stat-Signature: iftzgtpxpfqoziomaeqp5pw6r6g4ezbn X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1738703922-444059 X-HE-Meta: U2FsdGVkX1/TT/LwFHUiWXcQI/X3eOF8akHmx2JgnsETWych1qdOq/8awxQTB+uXgaMyXXuJMr0QtUGGbmpNaBIOMRc2cX+6asaugCCGdj4MYfCves+4E/suM/LUpP2mbd9j8sD9WeXeyYnaPxaat6p2P3wIJy82C+E0sJ1dd9/KzL8S2uFWpjRHUCRn1+qQODz82bevQ/+3aH/iI9gI4NchYpVE5jubvuh1168X9KCZu1/0fNGEU2w9k1dPFc7ZuOX+FZCARER7cFbxlPXlDEz7EVCx6YHbepNhqU3IEhiy2wMGOlcblhhXxEzevWXFLlN3E1QIHMdrtSVZxownXiVFHzqslVHm+rIhdZkGToRj1x7RKp8tteP3Zwjyoj0l8dxh/ZIqt+fOlM+AhbL0JYRVL1Z5+cVS0AYLRn1gP0LQ3KU4YaqVJVAPXCVsIXAj8CUZDzeBez0HhSqAUGpjBe6kP+dq/C0xlBQHn9yotDQBHg37ksD7JuGCHNp7vAY/k8XRyoHSGs2CDAGlsOm+Jxo26cfRklF9lHZDAJuyyoMgZQxgLxvgWUjRj2YzmloHRqm0ZVSzyVuuXVcnmWiTn7RtH7WwMFwJZKOhyqySwDRiqbTAVactAQtVwrUuscmJIjrhYaY5j2VIawX8VPUkrtCjWEY/tdENMAInvc+BNCDE4XWtkMzdjcFUm2MmtVGOw1r67YCvUUhFOXw8s9jfxVApTKgXhAbI/jsZySdN1ZLO8fYMvHyHHOv/8GAlFdHBOTofOmNy6MwoN7TixdK/pqscqK1MFUupHw/1YmWldUr/uLn/p2gpltXFqXPu7jliLjrGxI6dDfCmFu6IwIKW0MsIom9hOhBJRb4Ft1IaJNQaRah2Xa8LB/59MUK2yGmvmgQ+Um7Vmxkf0WzrweJ+YypIyDqF64z4TdKHUToIL3qev6EI2Ss5kXfuP/DzmjW2Kf1EGufFZOQ4QS8vBKe nqIQew94 vuR3FTc728bbiAv8cfxFQgjbw9XT+JYWRW+9Y8eQ8234u69t4cfCfcKCzxz3iu4idn8L5mCYH/kBqlbSbyHGUyjGUJXzyWBSlj3DaSLnTl5l5MJYIEmb/Gf7k0SjoVup6OvXk4pUGaHSpl8yittngpY0pybBEuR7GpogBzop4puU14Pz8foxDsu9un3cXhByVDJIBaTzfvkMGCpqmuzc5/NmMoGpMjgBI7gGYqJ81eYiY9FQ9LKk1zOGuTxOcLhTsTTHZyBcu1VawGh2qislVr7vHab4Elu2pSoGx1JJ3l9+CAm+10I1/q8m7qpd+HinAGO3mypUGS2YJiR0jhggDs/VF2ZlhVR/ItpmAIxHCsVHgnZfpZfILoefy5q/+a47gBBPLtBbAO/NdQMr/qNYg1X4P7Bqdy1OKbPc39A+uVn9IOHOPC/fn9UKdWTSAmUFbIeuy3pOMFDf9fQ+T2AW0PjzL4dmGGfr30IUkz7aZ7L0mFdpn5GaEa7lc5va0l7y29fTC X-Bogosity: Unsure, tests=bogofilter, spamicity=0.499285, 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 2/5/25 5:47 AM, David Hildenbrand wrote: > On 04.02.25 21:41, David Hildenbrand wrote: >> On 04.02.25 21:26, Jason Gunthorpe wrote: >>> On Tue, Feb 04, 2025 at 09:05:47PM +0100, David Hildenbrand wrote: >>>> Fully agreed, this is going into the right direction. Dumping what's >>>> mapped >>>> is a different story. Maybe that dumping logic could simply be >>>> written in C >>>> for the time being? >>> >>> ? >>> >>> Isn't dumping just a >>>     decode pte -> phys_to_virt() -> for_each_u64(virt) -> printk? >>> >> >> IIUC, the problematic bit is that you might not have a directmap such >> that phys_to_virt() would tell you the whole story. > > ... but it's late and I am confused. For dumping the *page table* that > would not be required, only when dumping mapped page content (and at > this point I am not sure if that is a requirement). > > So hopefully Asahi Lina can clarify what the issue was (if there is > any :) ). Yes, the crash dumper has to dump the mapped page content. In fact, I don't care about the page tables themselves other than PTE permission bits, and the page tables alone are not useful for debugging firmware crashes (and aren't even included in the dump verbatim, at least not the kernel-allocated ones). The goal of the crash dumper is to take a complete dump of firmware virtual memory address space (which includes the kinds of memory I mentioned in [1]). The output is an ELF format core dump with all memory that the GPU firmware can access, that the kernel was able to successfully dump (which should be everything except for MMIO if the bootloader/DT have the right reserved-memory setup). I *think* phys_to_virt should work just fine for *this* specific use case on this platform, but I'm not entirely sure. I still want to use the various pfn check functions before doing that, to exclude ranges that would definitely not work. I don't really want to write any part of the driver in C, but whatever logic is required, I don't think there should be a good reason for that. We can export the C functions required to Rust code in some form, we just need to decide what form that should be. Worst case, Rust drivers can directly access C functions via the `bindings` crate, though that's something I want to avoid (even if there's only a very thin or trivial Rust abstraction layer, there should be *something* so at least we get Rust docs and the ability to make subtle improvements to the interface/types/etc). [1] https://lore.kernel.org/rust-for-linux/1e9ae833-4293-4e48-83b2-c0af36cb3fdc@asahilina.net/ ~~ Lina