From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 689F6610B for ; Mon, 13 Oct 2025 07:15:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760339728; cv=none; b=lnf3IqLmqf+WfxJylIxforJXQtrhTaVDq4EkZTtkx0UdNZT+2xx7v8rtBoAXMq5H7NSZJCr3ft7RLQET0B5jq1Ygk72zak2z3+4S9wQIEBnauMmSC0rHjyT/XGA4XhBxQFDWgnkflOifJPmfTKERD+e7MVnkH3iHCSiJmPfXb/M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760339728; c=relaxed/simple; bh=uvOYiLSxO8hALg+pTzVPPipnk2Sbv0WPw08PuGx/Bl8=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=XnpJip93vpwrxWCS1YnUhFbjrGcLfftn3gfcHL5Amu2+OzKGueY2d8tZ8v+HFvmc3FzYG3HB2HWRPVSPdjHG56NTDX6WVa58juNv3z5nVubiH2dmJNHSeaxhRS2B3SUYF9AlFXnN/zp9Pwc9uvb1hliYwQgEnmU7mytiO2JSd4I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=vMs1HnXQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="vMs1HnXQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0523DC4CEE7; Mon, 13 Oct 2025 07:15:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1760339728; bh=uvOYiLSxO8hALg+pTzVPPipnk2Sbv0WPw08PuGx/Bl8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=vMs1HnXQwkSeF94h3e7R10x0EspzZ1aioKalEcHuTuqAYkzk/H3Ef1JVV2Gu7P8vb QpSDLQ/DHEkz9ig8iRGrQvGe4jsDDDbpShHMr83UahC3G/WbMNdxvA0cMAESvjz++m gu0RYAVaNSpoYLv6gME5VJqKhgyxZTWtaxGLnyu9GOCrsA9HB9T9jLOx+CxVkBHqVB MkPeWDfLT5RYcv6zeS45dTzMz1NF2llSOHnXyeLR29rDScU8iBs4qYhDwtA+Mg308O uhQiuiA++IyByh1o6D7PflLrgjpYlU07SaV+1Pfo/rMGkzOnG80KjvsoO7EIsKT0CG 7QI1lLNVLpJSg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1v8CmD-0000000DQvL-2UPH; Mon, 13 Oct 2025 07:15:25 +0000 Date: Mon, 13 Oct 2025 08:15:25 +0100 Message-ID: <868qhfxofm.wl-maz@kernel.org> From: Marc Zyngier To: Jinqian Yang Cc: , , Alex Williamson , Thomas Gleixner , Zenghui Yu , jiangkunkun , Zhou Wang , liuyonglong Subject: Re: [Question] QEMU VM fails to restart repeatedly with VFIO passthrough on GICv4.1 In-Reply-To: <5269ecde-be8e-4920-a76f-882da1475d5d@huawei.com> References: <5269ecde-be8e-4920-a76f-882da1475d5d@huawei.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: yangjinqian1@huawei.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, alex.williamson@redhat.com, tglx@linutronix.de, yuzenghui@huawei.com, jiangkunkun@huawei.com, wangzhou1@hisilicon.com, liuyonglong@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 13 Oct 2025 03:56:20 +0100, Jinqian Yang wrote: > > Hi, all > > On a GICv4.1 environment running kernel 6.16, when launching VMs with > QEMU and passing through VF devices, after repeatedly booting and > killing the VMs hundreds of times, the host reports call traces and the > VMs become unresponsive. The call traces show VFIO call stacks. > > [14201.974880] BUG: Bad page map in process qemu-system-aar > pte:fefefefefefefefe pmd:8000820b1ba0403 > [14201.974895] addr:0000fffdd7400000 vm_flags:80240644bb > anon_vma:0000000000000000 mapping:ffff08208e9b7758 index:401eed6a > [14201.974905] file:[vfio-device] fault:vfio_pci_mmap_page_fault > [vfio_pci_core] mmap:vfio_device_fops_mmap [vfio] mmap_prepare: 0x0 > read_folio:0x0 > [14201.974923] CPU: 2 UID: 0 PID: 50408 Comm: qemu-system-aar Kdump: > loaded Tainted: G O 6.16.0-rc4+ #1 PREEMPT > [14201.974926] Tainted: [O]=OOT_MODULE > [14201.974927] Hardware name: To be filled by O.E.M. To be filled by > O.E.M./To be filled by O.E.M., BIOS HixxxxEVB V3.4.7 09/04/2025 > [14201.974928] Call trace: > [14201.974929] show_stack+0x20/0x38 (C) > [14201.974934] dump_stack_lvl+0x80/0xf8 > [14201.974938] dump_stack+0x18/0x28 > [14201.974940] print_bad_pte+0x138/0x1d8 > [14201.974943] vm_normal_page+0xa4/0xd0 > [14201.974945] unmap_page_range+0x648/0x1110 > [14201.974947] unmap_single_vma.constprop.0+0x90/0x118 > [14201.974948] zap_page_range_single_batched+0xbc/0x180 > [14201.974950] zap_page_range_single+0x60/0xa0 > [14201.974952] unmap_mapping_range+0x114/0x140 > [14201.974953] vfio_pci_zap_and_down_write_memory_lock+0x3c/0x58 > [vfio_pci_core] > [14201.974957] vfio_basic_config_write+0x214/0x2d8 [vfio_pci_core] > [14201.974959] vfio_pci_config_rw+0x1d8/0x1290 [vfio_pci_core] > [14201.974962] vfio_pci_rw+0x118/0x200 [vfio_pci_core] > [14201.974965] vfio_pci_core_write+0x28/0x40 [vfio_pci_core] > [14201.974968] vfio_device_fops_write+0x3c/0x58 [vfio] > [14201.974971] vfs_write+0xd8/0x400 > [14201.974973] __arm64_sys_pwrite64+0xac/0xe0 > [14201.974974] invoke_syscall+0x50/0x120 > [14201.974976] el0_svc_common.constprop.0+0xc8/0xf0 > [14201.974978] do_el0_svc+0x24/0x38 > [14201.974979] el0_svc+0x38/0x130 > [14201.974982] el0t_64_sync_handler+0xc8/0xd0 > [14201.974984] el0t_64_sync+0x1ac/0x1b0 > [14201.975025] Disabling lock debugging due to kernel taint > > This value (0xfefefefefefefefe) is very special - it's a "poison" value. > QEMU or the VFIO driver may have attempted to access or manipulate a > page that has already been freed. > > Thanks in advance for any insights! I have no insight whatsoever, but there is very little in this report to go on. So here are the questions you should ask yourself: - How specific is this to GICv4.1? - Does it stop triggering if you disable direct injection? - What makes you think this value is explicitly a poison value rather than some other data? - Who writes this "poison" data? - Does it reproduce on 6.17 rather than a dodgy 6.16-rc4? - What operation was QEMU performing on the device when this happens? - Using what devices passed to the guest? - What do the usual debug options (KASAN, lockdep) report? - What is so specific about this HW? - What is this out-of-tree module? - Have you tried without it? These are the questions I'd ask myself before even posting something, because each and every one of them is relevant. There are probably more, but once you have answered these question, you should be able to figure out what the gaps are in your understanding of the problem. Thanks, M. -- Without deviation from the norm, progress is not possible.