From patchwork Fri Oct 25 15:11:22 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: David Hildenbrand X-Patchwork-Id: 13850917 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 A64DFD0C61F for ; Fri, 25 Oct 2024 15:11:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E628F6B007B; Fri, 25 Oct 2024 11:11:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E12446B0082; Fri, 25 Oct 2024 11:11:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CDA186B0083; Fri, 25 Oct 2024 11:11:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id B1FE56B007B for ; Fri, 25 Oct 2024 11:11:53 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 847501C6914 for ; Fri, 25 Oct 2024 15:11:30 +0000 (UTC) X-FDA: 82712463918.24.835729B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf07.hostedemail.com (Postfix) with ESMTP id E5DB440018 for ; Fri, 25 Oct 2024 15:11:23 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dewpe2RA; spf=pass (imf07.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729868956; 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: references:dkim-signature; bh=QjXxCmbGyjt3cTdnXge0Xs0ObzNL+3C4WmSnlfC/eHc=; b=jal+Tt7MESVY4T6aeHR7PdHhVOy/+C7EdYPK3xupl8g1FXHn6BOlPxKSiyGn0bOH5FdlNB 6vq/MPTsyKPAFTbfik89xRUlY80tHGjp15awyiYD+as6mjVkAJOH+5n5wr0pPq9nMO5iRj X5hJ0PfgtkvXRFFZshDFoyxH71JG7DI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729868956; a=rsa-sha256; cv=none; b=db6xBh3c0muRUetz2HdM6E6RE83ENgaAzgPCbZw+DjoyaRODRhzQxgnzXSOtm/InqAUo/r Wpat+s7YIYV6S9JUOcToHrKicqbF/63pfKO4Dztf4urwLTkJZrVodHd8xQhRP6w/hUkkk3 qnmnmM5xVYBols9ktVsi4TMYvKPjtRE= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dewpe2RA; spf=pass (imf07.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1729869110; h=from:from: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; bh=QjXxCmbGyjt3cTdnXge0Xs0ObzNL+3C4WmSnlfC/eHc=; b=dewpe2RAQYnz0Mr+DRx61PXHf+8uJAnef7yw5VteXzzMT84JiQf6i5j4xkbuVhSqPfwVjk CSGRcnqKgBV7dO+3CNn+c5ZMePMnKN3kQhGjGgFCTg+XzYRm6blCgZOA2/6flCb6LMvvbW uvk89y0Hxk+B/J1ViCm2yB9p9VVgVu0= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-283-ADxDlDjTM6qViV2-qHlzTA-1; Fri, 25 Oct 2024 11:11:47 -0400 X-MC-Unique: ADxDlDjTM6qViV2-qHlzTA-1 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (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 mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id AF56C1955E85; Fri, 25 Oct 2024 15:11:44 +0000 (UTC) Received: from t14s.redhat.com (unknown [10.22.65.27]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 45618300018D; Fri, 25 Oct 2024 15:11:35 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, linux-s390@vger.kernel.org, virtualization@lists.linux.dev, kvm@vger.kernel.org, linux-fsdevel@vger.kernel.org, kexec@lists.infradead.org, David Hildenbrand , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , "Michael S. Tsirkin" , Jason Wang , Xuan Zhuo , =?utf-8?q?Eugenio_P=C3=A9rez?= , Baoquan He , Vivek Goyal , Dave Young , Thomas Huth , Cornelia Huck , Janosch Frank , Claudio Imbrenda , Eric Farman , Andrew Morton Subject: [PATCH v1 00/11] fs/proc/vmcore: kdump support for virtio-mem on s390 Date: Fri, 25 Oct 2024 17:11:22 +0200 Message-ID: <20241025151134.1275575-1-david@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E5DB440018 X-Stat-Signature: zqxd8b97948feg6m1crc8bm9uokjbtpf X-HE-Tag: 1729869083-27514 X-HE-Meta: U2FsdGVkX18RopHLJKhf2FTO5bkns7j9djGpF/ps9qOjGha7aqiJKSMSCCyi2HMpv6pK4kwv6SjpftXkYTPVDi25wd3jw0t4uDPYF9Qg3xg/I/wR56E9GBsgF0OjAqMmAzeVv7cIZot8ruTkYIq11vb5Vg0J7gr1xtB0tDljx8IQ+KdgeOG01KvzMnnPUqhLpaUx5JZ8qzTWuiuKJR/8rUTne1c8k8b1Xznzz9cCga3CqGG8fY1M8cSVgorPos5XaT3ayOOxxMi2rmamCYNz/HXMeUt7BeQmRdtyYXZ0t0+Us3p2Xy1pvlX3NuHprfYoVhbWrupvjk/bF5fozf3WRId0tMzPV6r81GcRTUn24xT+GloDhOR+xixJ/W8w+kXWvBe4xaDGwvfqUW2K6GUVoqVEN9ZX4igeSwmmutWLV3dTcDBRn0C6yH3mP8uFRkM0cD0Yy3C2HqwTSuhW9Z0elALoG0NEzFPlaEe/21X70/o6/Xecyl5qBSHh1Ak4zd8bWpQzXDGmzl6UFOIrxf0P+H3/+TI5/Ito6irKvMAJg/fumS2D6QU9IQpBf5ADWHnw/XC8lJ0v4TImy5KtZN07x5R7xWoVo0/Pus609AWMIS8i0fHEuissIzn3XEswxRdY4t7mtP/+POaH6FUElxvkHByip12rW+YC09hBbGotCz8Nrv9Y7DvtvzyzmO39m5lHHkBj2Sw5rbd/Q2hNVlVV1dqXuyMY01knEToku26OZ1OjoW/aSBpyrvCxO56MkKHcdEsEMj092zuBkr2i1OLErkHJKvvIA8a3f31GRGaTMCv4LFP1j/kH21eqPVMBZrMCBmyLotwxBYqWT/xY6MlHCWQuArySpRVEXMJwhETtjDxxGHlYU6mquFzpcTmXGMlEh8FSJn1M8qgCMBb84KiXBEL0jMMKVqX3R6XSSWcN2I8t6OQZPyw+NAfT0XreiVdNjERzbI6GjnJQKA4ix3e dz63BR+P EY/Np/lHSp8+9b6zHjK2hNTl54P8GkHVx+9JOvs8Z51xQ2ji8eMizC295hicwo6ut5Xc3Dh91Biptr/30/rQqxgSGYgYP0cMwUvCUsSPaSzrkMJ9Pihivb4kJh//VUlnFygzjspwS1kSKWf5qAdL7I8ZQb4HJpFD7EtIcLwLv3VOWtASFgAKjgoVC5b7Yu667EqqlgIIBUlvyHt/vflzIlv7D+CXF0jc+bAHUHHhVp7fmJBj1TLOfCClY+soUHNaq5s55kr2eCJZ9swDTHxI9yYTurnlO5ChWjxyt4qKzihTH96oix54tutdwHDpmqNYws9C8LaKjNEAjfBmqwvZko04CikyE3Wz+XLyF95fPOT6k1WL4QiCwD37BPQGyeoJSsnnTnwj/ElOWp+YhomkMzls9240HP/FMcZ4u8L/zDB3c5SVTFDfhw8XVb6PeqCHb4oRFS7eTU1w09b28cdfq1802+i7AITcdpP/SaG+fN+DMEn99yljiMZL5Snu2G/jzVJg2 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: This is based on "[PATCH v3 0/7] virtio-mem: s390 support" [1], which adds virtio-mem support on s390. The only "different than everything else" thing about virtio-mem on s390 is kdump: The crash (2nd) kernel allocates+prepares the elfcore hdr during fs_init()->vmcore_init()->elfcorehdr_alloc(). Consequently, the crash kernel must detect memory ranges of the crashed/panicked kernel to include via PT_LOAD in the vmcore. On other architectures, all RAM regions (boot + hotplugged) can easily be observed on the old (to crash) kernel (e.g., using /proc/iomem) to create the elfcore hdr. On s390, information about "ordinary" memory (heh, "storage") can be obtained by querying the hypervisor/ultravisor via SCLP/diag260, and that information is stored early during boot in the "physmem" memblock data structure. But virtio-mem memory is always detected by as device driver, which is usually build as a module. So in the crash kernel, this memory can only be properly detected once the virtio-mem driver started up. The virtio-mem driver already supports the "kdump mode", where it won't hotplug any memory but instead queries the device to implement the pfn_is_ram() callback, to avoid reading unplugged memory holes when reading the vmcore. With this series, if the virtio-mem driver is included in the kdump initrd -- which dracut already takes care of under Fedora/RHEL -- it will now detect the device RAM ranges on s390 once it probes the devices, to add them to the vmcore using the same callback mechanism we already have for pfn_is_ram(). To add these device RAM ranges to the vmcore ("patch the vmcore"), we will add new PT_LOAD entries that describe these memory ranges, and update all offsets vmcore size so it is all consistent. Note that makedumfile is shaky with v6.12-rcX, I made the "obvious" things (e.g., free page detection) work again while testing as documented in [2]. Creating the dumps using makedumpfile seems to work fine, and the dump regions (PT_LOAD) are as expected. I yet have to check in more detail if the created dumps are good (IOW, the right memory was dumped, but it looks like makedumpfile reads the right memory when interpreting the kernel data structures, which is promising). Patch #1 -- #6 are vmcore preparations and cleanups Patch #7 adds the infrastructure for drivers to report device RAM Patch #8 + #9 are virtio-mem preparations Patch #10 implements virtio-mem support to report device RAM Patch #11 activates it for s390, implementing a new function to fill PT_LOAD entry for device RAM [1] https://lkml.kernel.org/r/20241025141453.1210600-1-david@redhat.com [2] https://github.com/makedumpfile/makedumpfile/issues/16 Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Alexander Gordeev Cc: Christian Borntraeger Cc: Sven Schnelle Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Xuan Zhuo Cc: "Eugenio Pérez" Cc: Baoquan He Cc: Vivek Goyal Cc: Dave Young Cc: Thomas Huth Cc: Cornelia Huck Cc: Janosch Frank Cc: Claudio Imbrenda Cc: Eric Farman Cc: Andrew Morton David Hildenbrand (11): fs/proc/vmcore: convert vmcore_cb_lock into vmcore_mutex fs/proc/vmcore: replace vmcoredd_mutex by vmcore_mutex fs/proc/vmcore: disallow vmcore modifications after the vmcore was opened fs/proc/vmcore: move vmcore definitions from kcore.h to crash_dump.h fs/proc/vmcore: factor out allocating a vmcore memory node fs/proc/vmcore: factor out freeing a list of vmcore ranges fs/proc/vmcore: introduce PROC_VMCORE_DEVICE_RAM to detect device RAM ranges in 2nd kernel virtio-mem: mark device ready before registering callbacks in kdump mode virtio-mem: remember usable region size virtio-mem: support CONFIG_PROC_VMCORE_DEVICE_RAM s390/kdump: virtio-mem kdump support (CONFIG_PROC_VMCORE_DEVICE_RAM) arch/s390/Kconfig | 1 + arch/s390/kernel/crash_dump.c | 39 +++-- drivers/virtio/Kconfig | 1 + drivers/virtio/virtio_mem.c | 103 +++++++++++++- fs/proc/Kconfig | 25 ++++ fs/proc/vmcore.c | 258 +++++++++++++++++++++++++--------- include/linux/crash_dump.h | 47 +++++++ include/linux/kcore.h | 13 -- 8 files changed, 396 insertions(+), 91 deletions(-)