From patchwork Wed Dec 4 12:54:39 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Hildenbrand X-Patchwork-Id: 13893711 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 ECC58E7716B for ; Wed, 4 Dec 2024 12:55:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 45C0A6B009B; Wed, 4 Dec 2024 07:55:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 407CF6B009C; Wed, 4 Dec 2024 07:55:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 25EA66B009D; Wed, 4 Dec 2024 07:55:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 049796B009B for ; Wed, 4 Dec 2024 07:55:15 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C03011C7839 for ; Wed, 4 Dec 2024 12:55:15 +0000 (UTC) X-FDA: 82857271728.30.D3F8038 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf23.hostedemail.com (Postfix) with ESMTP id E712A140011 for ; Wed, 4 Dec 2024 12:55:03 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=XzIKmk5J; spf=pass (imf23.hostedemail.com: domain of dhildenb@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=dhildenb@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=1733316906; 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=DHduTfm8MEvatODJJecU9qsghwDNoQQYbaQi+lekCuQ=; b=zU16vxTWLzwvFVDKmmdgJOpo+GzFRwfOr6umCZW18iJNoKuCO0X5+hjyEKhnfwmD+4QMEl hOIlDjrKdREf235nggeRuJyNiu0IJJYaRF1aJNgFgZ91GNH1os+FIE03flen3H4VrSV2Wa csj6SBEdYaUCiqGFxjV9PVmNC+JCalE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733316906; a=rsa-sha256; cv=none; b=y7dh1I20CVGliuJqdBixDcVjClnmACYsk2nzGLxVPiP2pdexAVpEoXXqo4T26gJjmlXjdh yLEXCUCKsVvrapDEr8eqL/4LkCK3T+OPb4YAYGT7c0cMgjAXPg9bV7D8rGYzNw22dJlYUl uLI1vSPVtqaNcPPfI7IZ3S5sQKj43zU= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=XzIKmk5J; spf=pass (imf23.hostedemail.com: domain of dhildenb@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=dhildenb@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=1733316912; 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: in-reply-to:in-reply-to:references:references; bh=DHduTfm8MEvatODJJecU9qsghwDNoQQYbaQi+lekCuQ=; b=XzIKmk5Jhco7eFHj3ybrbAKNEJpZWutsGPg01UuLnAfQ2IunfsyLctBL/9bLGktGbx8E9h zCHSfiwfSydljhTWmOOndNd9eRK5WNyHDqP6QlSb3fw0vN05e2KR+vp4Gy3AT7suzZ2NES SZzQMs+8P0DpGytKw4nxrNxt+PF4TY0= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-212-UaT15q45OaKvutlMJs2OpQ-1; Wed, 04 Dec 2024 07:55:11 -0500 X-MC-Unique: UaT15q45OaKvutlMJs2OpQ-1 X-Mimecast-MFC-AGG-ID: UaT15q45OaKvutlMJs2OpQ Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-434a51e44d0so55172555e9.3 for ; Wed, 04 Dec 2024 04:55:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733316910; x=1733921710; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DHduTfm8MEvatODJJecU9qsghwDNoQQYbaQi+lekCuQ=; b=nDVy1RqvQO1JBCF5R1+QWnmtzcARZ5zVR38dmVx8yysPbqXlXmGsjCarmEdbAKPJON TALs6SXWApCIvK4bw2pQLiUlI2Xg91y/TgxL1Hf81nHdBcxVsQMEYiuN2va38pNZYWRv 3/hM6FswmxctXA143EZLCfdId4v0IB4xD/2oX/sStuIUMoa0wx7P+ZM/Xn7kg2/m1qVn D2JaeHdDwCUjjwEUtPjhdBelLzBHugIDjsfWV7uAZMAVzB1kn4g7uWgxGJEzdV9y9AAn r75pn8GdDeUg2TBJZQtlmDAc8bRdzVIsYB7qKY4Y40/TYzKYAZsIFbmFcQi0+qx64LNd bacA== X-Gm-Message-State: AOJu0YxycwardW6GCyT/6AG0YpODCqmJnAOFARfPh9HxQRA0yCMDK/ha w4mMP5UPKZ00SvaqcDMyCmBnThFIomTy3okS2DoBOe5kMeLNr+sz5sUgsNcD6FBHOVk7O/dpNoe 7iWu3MUW0H4oqELbqvUx6Sp+vApsM6GWFE20pldSR0yHmT3BQ X-Gm-Gg: ASbGnctvv2McP1rmF2tPvoj4+AdNSKi2cfzvEgV+wXEDC9uCJaNNnDNcAvuBtZk1ncH uXIbCjhM7G5muHLZUIxfIg3YXSsP/xnjwb299j3PwGPkLm6QdjBKicWnkYVs/Ah9DnhxrRv3LoA gGN9lJnmVZ/bTW/4ZOdx6FwAoR+hxgU+a7QcfI0R2iRh/DxKBvU5UXYDB54pk490kHRDf9dlKen Cwv55jCaddsqP5UVuji4dEJEmdP6NQpW6qaD6XBC/bd97lsrb4NZwxlXI5pFlZiciYPOCAp42Uo LJLSuJfEQfwC5iMZJ3i2FI3TG/Sbpe/tYLY= X-Received: by 2002:a05:600c:1c88:b0:434:9df4:5472 with SMTP id 5b1f17b1804b1-434d0a15068mr60073465e9.31.1733316910496; Wed, 04 Dec 2024 04:55:10 -0800 (PST) X-Google-Smtp-Source: AGHT+IGWq3Nj3w3HYlBbZnRWgOzE8l6L8boPfRZN2lwS+xZGCeTjU6KZId+aHdXHdM4P1FN9VEFBqg== X-Received: by 2002:a05:600c:1c88:b0:434:9df4:5472 with SMTP id 5b1f17b1804b1-434d0a15068mr60073175e9.31.1733316910084; Wed, 04 Dec 2024 04:55:10 -0800 (PST) Received: from localhost (p200300cbc70be10038d68aa111b0a20a.dip0.t-ipconnect.de. [2003:cb:c70b:e100:38d6:8aa1:11b0:a20a]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-434d5280746sm23704445e9.21.2024.12.04.04.55.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Dec 2024 04:55:09 -0800 (PST) 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 v2 08/12] fs/proc/vmcore: introduce PROC_VMCORE_DEVICE_RAM to detect device RAM ranges in 2nd kernel Date: Wed, 4 Dec 2024 13:54:39 +0100 Message-ID: <20241204125444.1734652-9-david@redhat.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: <20241204125444.1734652-1-david@redhat.com> References: <20241204125444.1734652-1-david@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: _9qO7NWANqpxFjKsN6O157lKt_iJnX8MP8v7CDRwb98_1733316911 X-Mimecast-Originator: redhat.com content-type: text/plain; charset="US-ASCII"; x-default=true X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: E712A140011 X-Stat-Signature: 97fuuibucb95bjhxmciz9j4jr3bg8kzo X-Rspam-User: X-HE-Tag: 1733316903-272011 X-HE-Meta: U2FsdGVkX1+qscgoLbXCK+02IHWAHFRf7YL5PBwObQSqT/iIeUnWSrOI9o0ambf/mTRSEzlPjsW1/LdmT4VPjbe0Dj4UZNwHjbZkdj/S3rl7RxIBjvAXoL/Uyh1QwOzFrXspkQw7+ziYyTAb8ScDmNTQTpxoR5s84QcjVg+yT4UAD/0fRLz3O885NCCDsrbR7cpMSAtZMnHz5Rh/zPKpU4ltMZ/NerNuljdkQFvYTUkLytvJL7MoEp5mqRnlDG9TVtdzPgyS2dgHLsitlhqbzI126wFFp7wdXlurYz13xFfgoBSNr0W4QBx4IEsBFkXtgYeno27B1eUATG59t5XeqntjpJ+kZikTxfuYKOKo7QLf6iX8p4kr1owl9yNk1r9csRuuLdGwahhPPu2Jeg5sBLNXa36TWa7lC0bOb0T+Z/mDDxs+zw50fZ49A+x7vaWGVJGJZlgWFe28U8SdRf9pslxVHvsLMQ72Y/5Z6XENQMGlkSwPt9k12nyNTgXOPpc8BYV5/JhYfc9vDYRVd/6r3n/Wu9NuLRHzBf8GgBj4LFp+eYF2zAF4Qb0uBBKh/29t1JnnU8Dsk+1X2nmyj4Zqv83EH+7tbjlIyAwZWCsqlNvBcy1M+iDs/c7h9zz6rTOa+uJS3Ixwoeslo/eWnljpaqQH/DVkmptPAHb/VsOyBza8W8OQMlJ2+QRgdx2SJwx6a/x3mjxP8DEe6MA0Xbf3BjofCH2jmrZYse9f7czDH2Xh9Uk4fGupHHxEi4xT6oKPR/w5NI2BiqihNKoykEKvG237KlrIHumM1DXRpEdfVc2Khvi4NEKJKcs/l39/73sJqLii2SJwxrzCVVrOgg2ujb9QucQq/RsxABN0OnsLrr6lDsaP4L7PoLdqZwTvXJ6PPXMPTuwZFxEZSIDQXd6puMbP0TPqkdjnTDAAXnJnGo6k5PlQJchCdZPtbesTqrob4dVEBEuh1c/rvIhJZXx HbmN6nr/ 30ywWGDk7hoO+2AWRfyA9mDoxukoNOatvx7wVkYjNT8WWx4I8W6tZvfBkPjWLw5fLNvk+vE4jBVuVil2AW1AkOQSrMiXomYFryaWPxjh4x9FORWcFb/cw5z1oQdeiQOJh/BVdncde8Y4P8gbNLYkeo3UNVq4UA1OfHR3eBmcEzxJX5Ad3IlgauBXQxv3xSmUh7XzF7vH3Ib+6De1/Vu3//t4ADw3NlmbM0QXWVww3EY83O8GCB5+XcOSpiyfdykXPsqVyw5iydEW6D68kIcpJe3rWetZ1KF/BzjoZ/nWLRZp/iB+waoriwMn2AJ1C+6GI7QlUNPYaMSX5hPhJN5EP+RiOUM7jT2oSd7KKVX3LZy+JwOAXPS1uH0RRBY2u0yqEQ0Wlt75C9Ea6PZf5qPjAb2LUxbGJLvYDM93JhB1i1yHW198M48fF5t4nSohYCD0eunll9fD9tbADj3ixNiUAH2MPjN2VY3USXM6DrRm0mF2OZAQ= 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: s390 allocates+prepares the elfcore hdr in the dump (2nd) kernel, not in the crashed kernel. RAM provided by memory devices such as virtio-mem can only be detected using the device driver; when vmcore_init() is called, these device drivers are usually not loaded yet, or the devices did not get probed yet. Consequently, on s390 these RAM ranges will not be included in the crash dump, which makes the dump partially corrupt and is unfortunate. Instead of deferring the vmcore_init() call, to an (unclear?) later point, let's reuse the vmcore_cb infrastructure to obtain device RAM ranges as the device drivers probe the device and get access to this information. Then, we'll add these ranges to the vmcore, adding more PT_LOAD entries and updating the offsets+vmcore size. Use a separate Kconfig option to be set by an architecture to include this code only if the arch really needs it. Further, we'll make the config depend on the relevant drivers (i.e., virtio_mem) once they implement support (next). The alternative of having a PROVIDE_PROC_VMCORE_DEVICE_RAM config option was dropped for now for simplicity. The current target use case is s390, which only creates an elf64 elfcore, so focusing on elf64 is sufficient. Signed-off-by: David Hildenbrand --- fs/proc/Kconfig | 18 +++++ fs/proc/vmcore.c | 156 +++++++++++++++++++++++++++++++++++++ include/linux/crash_dump.h | 9 +++ 3 files changed, 183 insertions(+) diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig index d80a1431ef7b..5668620ab34d 100644 --- a/fs/proc/Kconfig +++ b/fs/proc/Kconfig @@ -61,6 +61,24 @@ config PROC_VMCORE_DEVICE_DUMP as ELF notes to /proc/vmcore. You can still disable device dump using the kernel command line option 'novmcoredd'. +config NEED_PROC_VMCORE_DEVICE_RAM + bool + +config PROC_VMCORE_DEVICE_RAM + def_bool y + depends on PROC_VMCORE && NEED_PROC_VMCORE_DEVICE_RAM + help + If the elfcore hdr is allocated and prepared by the dump kernel + ("2nd kernel") instead of the crashed kernel, RAM provided by memory + devices such as virtio-mem will not be included in the dump + image, because only the device driver can properly detect them. + + With this config enabled, these RAM ranges will be queried from the + device drivers once the device gets probed, so they can be included + in the crash dump. + + Relevant architectures should select NEED_PROC_VMCORE_DEVICE_RAM. + config PROC_SYSCTL bool "Sysctl support (/proc/sys)" if EXPERT depends on PROC_FS diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c index e7b3cde44890..6dc293d0eb5b 100644 --- a/fs/proc/vmcore.c +++ b/fs/proc/vmcore.c @@ -79,6 +79,8 @@ static bool vmcore_opened; /* Whether the vmcore is currently open. */ static unsigned int vmcore_open; +static void vmcore_process_device_ram(struct vmcore_cb *cb); + void register_vmcore_cb(struct vmcore_cb *cb) { INIT_LIST_HEAD(&cb->next); @@ -90,6 +92,8 @@ void register_vmcore_cb(struct vmcore_cb *cb) */ if (vmcore_opened) pr_warn_once("Unexpected vmcore callback registration\n"); + if (!vmcore_open && cb->get_device_ram) + vmcore_process_device_ram(cb); mutex_unlock(&vmcore_mutex); } EXPORT_SYMBOL_GPL(register_vmcore_cb); @@ -1535,6 +1539,158 @@ int vmcore_add_device_dump(struct vmcoredd_data *data) EXPORT_SYMBOL(vmcore_add_device_dump); #endif /* CONFIG_PROC_VMCORE_DEVICE_DUMP */ +#ifdef CONFIG_PROC_VMCORE_DEVICE_RAM +static int vmcore_realloc_elfcore_buffer_elf64(size_t new_size) +{ + char *elfcorebuf_new; + + if (WARN_ON_ONCE(new_size < elfcorebuf_sz)) + return -EINVAL; + if (get_order(elfcorebuf_sz_orig) == get_order(new_size)) { + elfcorebuf_sz_orig = new_size; + return 0; + } + + elfcorebuf_new = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, + get_order(new_size)); + if (!elfcorebuf_new) + return -ENOMEM; + memcpy(elfcorebuf_new, elfcorebuf, elfcorebuf_sz); + free_pages((unsigned long)elfcorebuf, get_order(elfcorebuf_sz_orig)); + elfcorebuf = elfcorebuf_new; + elfcorebuf_sz_orig = new_size; + return 0; +} + +static void vmcore_reset_offsets_elf64(void) +{ + Elf64_Phdr *phdr_start = (Elf64_Phdr *)(elfcorebuf + sizeof(Elf64_Ehdr)); + loff_t vmcore_off = elfcorebuf_sz + elfnotes_sz; + Elf64_Ehdr *ehdr = (Elf64_Ehdr *)elfcorebuf; + Elf64_Phdr *phdr; + int i; + + for (i = 0, phdr = phdr_start; i < ehdr->e_phnum; i++, phdr++) { + u64 start, end; + + /* + * After merge_note_headers_elf64() we should only have a single + * PT_NOTE entry that starts immediately after elfcorebuf_sz. + */ + if (phdr->p_type == PT_NOTE) { + phdr->p_offset = elfcorebuf_sz; + continue; + } + + start = rounddown(phdr->p_offset, PAGE_SIZE); + end = roundup(phdr->p_offset + phdr->p_memsz, PAGE_SIZE); + phdr->p_offset = vmcore_off + (phdr->p_offset - start); + vmcore_off = vmcore_off + end - start; + } + set_vmcore_list_offsets(elfcorebuf_sz, elfnotes_sz, &vmcore_list); +} + +static int vmcore_add_device_ram_elf64(struct list_head *list, size_t count) +{ + Elf64_Phdr *phdr_start = (Elf64_Phdr *)(elfcorebuf + sizeof(Elf64_Ehdr)); + Elf64_Ehdr *ehdr = (Elf64_Ehdr *)elfcorebuf; + struct vmcore_range *cur; + Elf64_Phdr *phdr; + size_t new_size; + int rc; + + if ((Elf32_Half)(ehdr->e_phnum + count) != ehdr->e_phnum + count) { + pr_err("too many device ram ranges\n"); + return -ENOSPC; + } + + /* elfcorebuf_sz must always cover full pages. */ + new_size = sizeof(Elf64_Ehdr) + + (ehdr->e_phnum + count) * sizeof(Elf64_Phdr); + new_size = roundup(new_size, PAGE_SIZE); + + /* + * Make sure we have sufficient space to include the new PT_LOAD + * entries. + */ + rc = vmcore_realloc_elfcore_buffer_elf64(new_size); + if (rc) { + pr_err("resizing elfcore failed\n"); + return rc; + } + + /* Modify our used elfcore buffer size to cover the new entries. */ + elfcorebuf_sz = new_size; + + /* Fill the added PT_LOAD entries. */ + phdr = phdr_start + ehdr->e_phnum; + list_for_each_entry(cur, list, list) { + WARN_ON_ONCE(!IS_ALIGNED(cur->paddr | cur->size, PAGE_SIZE)); + elfcorehdr_fill_device_ram_ptload_elf64(phdr, cur->paddr, cur->size); + + /* p_offset will be adjusted later. */ + phdr++; + ehdr->e_phnum++; + } + list_splice_tail(list, &vmcore_list); + + /* We changed elfcorebuf_sz and added new entries; reset all offsets. */ + vmcore_reset_offsets_elf64(); + + /* Finally, recalculate the total vmcore size. */ + vmcore_size = get_vmcore_size(elfcorebuf_sz, elfnotes_sz, + &vmcore_list); + proc_vmcore->size = vmcore_size; + return 0; +} + +static void vmcore_process_device_ram(struct vmcore_cb *cb) +{ + unsigned char *e_ident = (unsigned char *)elfcorebuf; + struct vmcore_range *first, *m; + LIST_HEAD(list); + int count; + + /* We only support Elf64 dumps for now. */ + if (WARN_ON_ONCE(e_ident[EI_CLASS] != ELFCLASS64)) { + pr_err("device ram ranges only support Elf64\n"); + return; + } + + if (cb->get_device_ram(cb, &list)) { + pr_err("obtaining device ram ranges failed\n"); + return; + } + count = list_count_nodes(&list); + if (!count) + return; + + /* + * For some reason these ranges are already know? Might happen + * with unusual register->unregister->register sequences; we'll simply + * sanity check using the first range. + */ + first = list_first_entry(&list, struct vmcore_range, list); + list_for_each_entry(m, &vmcore_list, list) { + unsigned long long m_end = m->paddr + m->size; + unsigned long long first_end = first->paddr + first->size; + + if (first->paddr < m_end && m->paddr < first_end) + goto out_free; + } + + /* If adding the mem nodes succeeds, they must not be freed. */ + if (!vmcore_add_device_ram_elf64(&list, count)) + return; +out_free: + vmcore_free_ranges(&list); +} +#else /* !CONFIG_PROC_VMCORE_DEVICE_RAM */ +static void vmcore_process_device_ram(struct vmcore_cb *cb) +{ +} +#endif /* CONFIG_PROC_VMCORE_DEVICE_RAM */ + /* Free all dumps in vmcore device dump list */ static void vmcore_free_device_dumps(void) { diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h index 5d61c7454fd6..2f2555e6407c 100644 --- a/include/linux/crash_dump.h +++ b/include/linux/crash_dump.h @@ -20,6 +20,8 @@ extern int elfcorehdr_alloc(unsigned long long *addr, unsigned long long *size); extern void elfcorehdr_free(unsigned long long addr); extern ssize_t elfcorehdr_read(char *buf, size_t count, u64 *ppos); extern ssize_t elfcorehdr_read_notes(char *buf, size_t count, u64 *ppos); +void elfcorehdr_fill_device_ram_ptload_elf64(Elf64_Phdr *phdr, + unsigned long long paddr, unsigned long long size); extern int remap_oldmem_pfn_range(struct vm_area_struct *vma, unsigned long from, unsigned long pfn, unsigned long size, pgprot_t prot); @@ -99,6 +101,12 @@ static inline void vmcore_unusable(void) * indicated in the vmcore instead. For example, a ballooned page * contains no data and reading from such a page will cause high * load in the hypervisor. + * @get_device_ram: query RAM ranges that can only be detected by device + * drivers, such as the virtio-mem driver, so they can be included in + * the crash dump on architectures that allocate the elfcore hdr in the dump + * ("2nd") kernel. Indicated RAM ranges may contain holes to reduce the + * total number of ranges; such holes can be detected using the pfn_is_ram + * callback just like for other RAM. * @next: List head to manage registered callbacks internally; initialized by * register_vmcore_cb(). * @@ -109,6 +117,7 @@ static inline void vmcore_unusable(void) */ struct vmcore_cb { bool (*pfn_is_ram)(struct vmcore_cb *cb, unsigned long pfn); + int (*get_device_ram)(struct vmcore_cb *cb, struct list_head *list); struct list_head next; }; extern void register_vmcore_cb(struct vmcore_cb *cb);