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 C853EC369CB for ; Tue, 29 Apr 2025 07:46:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 386FD6B0005; Tue, 29 Apr 2025 03:46:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 30E496B0006; Tue, 29 Apr 2025 03:46:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D5D86B0007; Tue, 29 Apr 2025 03:46:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id F0B466B0005 for ; Tue, 29 Apr 2025 03:46:26 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BE3CDC8675 for ; Tue, 29 Apr 2025 07:46:27 +0000 (UTC) X-FDA: 83386298814.12.5437ECA Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf23.hostedemail.com (Postfix) with ESMTP id 081BA140004 for ; Tue, 29 Apr 2025 07:46:25 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="nAKxT/Zb"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf23.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745912786; a=rsa-sha256; cv=none; b=2S6K4mKBRA2M60+Hx5yjSYJPsSjF0D6mu4qD2uT8rEp57Xzb3T8+raWnRk/VjCUeRukcb3 oIQ+xOvDC6SXHMiYe+4Wmt9L3iHnBDrUUZwlxiiSxveWmRRZZ/eeUxSuvyPeIbYT2u0giA ldmBSvAKZf92EPjMeh4GjOomvZRJUFM= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="nAKxT/Zb"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf23.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745912786; 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=e7/JiDtNFGkaRmW1C9ab8Vosg4q3dueHbxvAcdpYTWo=; b=wiymLn2PXmXlO1vM4xBkYB51QJK/qjRuOCuibtypX87B0H7UOfJg9Z3dbh3mfSsYMAjI4Y Fu+JO7xUD2v/2zyRNVifTqkTCK7Sq0eZh6RdJysp9o0QyUcdcOIWfpezTdrCZDvYxqMWFf arsiaFvDy8yYJHK7UWhpxhvotkgj1Vo= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id BABC05C271E; Tue, 29 Apr 2025 07:44:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9E38C4CEE3; Tue, 29 Apr 2025 07:46:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745912784; bh=B1Tjq/VEc9BEwLRkXSe5xppoiP7KBXAstgtmIpFfjzQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nAKxT/ZbCsUrHTc0TFhc2F6M8M7au2948y4Fk7tEIqMVtVYYPiP0rMB/9Hl7ejftf oPTkZgOvWs7LnFwvmmi/b+JOXLVlZ32qbT5UJuyBbFS4Ff/tOCzLkY6oHiNaF5YfbT V5W7PcNvqFH1ZOQXMgEo8xlOmOilULNGgiI5UdPcUpNxDY4STfSTn2qcCvJmRCTdEH oDaszDKucZmHM+pP6xl4+kkqQ3mXjlFshDGy3nvaicj5P7vGMJfiJ9rl9No9tZvMgr uUf60fSs3EGuW18sh6pUHFDGD6mXfdYiLLZpqDt2n3TNog7qmtBSDUvstQYXcFCtPM 8Q4diqUGdRqQw== Date: Tue, 29 Apr 2025 10:46:16 +0300 From: Mike Rapoport To: David Hildenbrand Cc: Tom Lendacky , "Kirill A. Shutemov" , Andrew Morton , Vlastimil Babka , Mel Gorman , "Kalra, Ashish" , Rick Edgecombe , linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, Michael Roth Subject: Re: SNP guest crash in memblock with unaccepted memory Message-ID: References: <64c04e6c-43b1-996b-f83d-5fb1751debaa@amd.com> <6fb7b4b6-3b2c-4f7c-9c84-a72cdac6f854@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6fb7b4b6-3b2c-4f7c-9c84-a72cdac6f854@redhat.com> X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 081BA140004 X-Stat-Signature: snqz6m7hqk8ojhb9rfkgs1xo58sg86fa X-Rspam-User: X-HE-Tag: 1745912785-162159 X-HE-Meta: U2FsdGVkX1/+WSZarOE38wgHCMFXJRNuO313kwIRSxxjaJTJ2t8lTQrQPXSt8P8hXAYluxIAlLjZyx8+cgV0POjU1yZ6KPyl2U1CEVkJGhQ4gqkEHIztIHyFSizqh4zmE/zb6rxA9BPK64pqzPsuKWPXDiDqdtYpErBNVLmtpmnj9J3yPxF4xX6bDxfhrBoGdqXizRhXw11oiiCVaFkgYWNTLWnXislcUYsWE7s9ugHRyFrDgbj1V4OhSfe8yUO+mlaEi/lehg9qtXtpw3Xw7tT3GnUYPszsZ1ppCIiKAp1VHDupPqcPqZRVGg6wdBTkWwzNyCFs31vqxVuvwOwHEHcPxMA2//O6s5mRUnsGgADVrt0xoICc2UxbEfvMtPtl/mmqZg4NjD7TMzvN339loMJU91kwsTxuVrve65cL/t2iaV3b0fQ7mMlf6hC1oUMqQ36qQkcvxvY8O621GpL/01zIsyi7Rq+rc/bJXfD7ro93boQVvpIkAe0ueqxYcJ+1eBZmEGnC1Jzwm6n6cp/HKH59zyI93jZK4XX4qR6bfgulBtIOnApkdzPeyODtdMLR5NG5eSFVICLJa4kgJ/+oDO075rLAjGa12Chr2zKRAVvJSftVFWssrWqu18x20BLopuupxqEm/j8lvf1eNu2fArG3uzntec8fNnhbYuRBKGAhYNsacvLSMU6T3eRXpJgDBt1ZcSA/qfxZPOEjJLble9MxnLZunJfK+JW5GHT1RT7PzRo3DsRiNWEFz5LtbSo60BT1x9Byr0VWCaux8Vzf4kX5aXXep7HGV55/K1tTgGdVu3u8wxQRsuG7LqnItbFJbxrd+Vqoff++CYXtzDxNPkt3ZLP8XJN3Ie92Ei+gXS+wbPitDz9Cy+nPpeZbWSZIOLeXKWcBswqGdY4DsFeVk6kE6ABYGHAEBK2c356hJ/M16ycbWBGD+g/R9/68g/Gc1LoAgWDTKNn3+7Gjbra 1OCltQor UW63ebrcpv0klLMG4jKPebNIRM88IF6IYiKVYaEsz4nDzlVx+2jaFilVO7YNrDQTmgyaiYHUmiWoyN9JrKoIpybhPUgcMhodejeEX609/CQdjP1VEjZL3k0HDnNzqXWIeQXDi4JdvCoiHlr3Gd65MvGbRg8efQOBXrKJgapzEtHBNn6uk2IamN+maEqVyjFHy5bmwlRn8VMZrP9e6bQ+Z7RwyiPTMX2ApwPbRH/uGL3yqVTjNxcKkBlGjmjNOt6HZo7iZZYAN1ZH9ApjhBSr7QMNiCA== 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 Mon, Apr 28, 2025 at 11:00:36PM +0200, David Hildenbrand wrote: > On 28.04.25 20:10, Tom Lendacky wrote: > > On 4/28/25 09:04, David Hildenbrand wrote: > > > On 27.04.25 17:01, Tom Lendacky wrote: > > > > Hi Kirill, > > > > > > > > Every now and then I experience an SNP guest boot failure for accessing > > > > memory that hasn't been accepted. I managed to get a back trace: > > > > > > > >    RIP: 0010:memcpy_orig+0x68/0x130 > > > >    Code: ... > > > >    RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006 > > > >    RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000 > > > >    RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00 > > > >    RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000 > > > >    R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78 > > > >    R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00 > > > >    memblock_double_array+0xff/0x310 > > > >    memblock_add_range+0x1fb/0x2f0 > > > >    memblock_reserve+0x4f/0xa0 > > > >    memblock_alloc_range_nid+0xac/0x130 > > > >    memblock_alloc_internal+0x53/0xc0 > > > >    memblock_alloc_try_nid+0x3d/0xa0 > > > >    swiotlb_init_remap+0x149/0x2f0 > > > >    mem_init+0xb/0xb0 > > > >    mm_core_init+0x8f/0x350 > > > >    start_kernel+0x17e/0x5d0 > > > >    x86_64_start_reservations+0x14/0x30 > > > >    x86_64_start_kernel+0x92/0xa0 > > > >    secondary_startup_64_no_verify+0x194/0x19b > > > > > > > > I don't know a lot about memblock, but it appears that it needs to > > > > allocate more memory for it's regions array and returns a range of memory > > > > that hasn't been accepted. When the memcpy() runs, the SNP guest gets a > > > > #VC 0x404 because of this. > > > > > > > > Do you think it is as simple as calling accept_memory() on the memory > > > > range returned from memblock_find_in_range() in memblock_double_array()? > > > > > > (not Kirill, but replying :) ) > > > > > > Yeah, we seem to be effectively allocating memory from memblock ("from > > > ourselves") without considering that memory must be accepted first. > > > > > > accept_memory() on the new memory (in case of !slab) should be the right > > > thing to do. > > > > Thanks, David. Let me add a call in for accept_memory in the !slab case > > and see if that resolves it. May take a bit to repro, but should find > > out eventually. > > > > I'll submit a patch once I verify. > > BTW, I was wondering if we could use memblock_alloc_range_nid() in > memblock_double_array(); maybe not that easy, just a thought. Not easy at all for memblock.reserved, memblock_double_array() makes sure to avoid memory that's being reserved in this call chain: memblock_alloc_range_nid() memblock_reserve() memblock_add_range() memblock_double_array() > -- > Cheers, > > David / dhildenb > -- Sincerely yours, Mike.