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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 886C3CCD185 for ; Mon, 13 Oct 2025 07:15:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=o+UAA/9LrTX4GEaNyzCoCJM4nYhqCmWPlihD2poYyMo=; b=gD3TO1ZPDD/rGqAQdzp6qdCtLZ L5oVO+QESkv/8uLP0YlnL8Hb8EyYqHU1iXceZQjdsDQHVyLa0RoBdfSBNe74wTF3blsw9dY3wl2Es C/shWJ+An1PAjV0AjD3h3iOIcR892AfHfOmkJnBRs/zBy7Mg3wNiTqsWP0n8cKBtiZKT+n7ojnW+o teWKfR6yhpld92yIXRJDwoZYgrMFVrDZO1aNWn8n+RgGk2uXXTW6hlfZmeRIxuKm8jka8+8yxIW10 7Aen/U3mdMvDsEOrqqsILMvT0ak7XBtsyR23qomUT7J3E2hYzJo4DMNFTbXEqLVJwziTpvOQvalGr PVjo2m9g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1v8CmI-0000000CTD0-0zOQ; Mon, 13 Oct 2025 07:15:30 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1v8CmG-0000000CTCZ-3FtA for linux-arm-kernel@lists.infradead.org; Mon, 13 Oct 2025 07:15:29 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 2601F43A5E; Mon, 13 Oct 2025 07:15:28 +0000 (UTC) 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) 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20251013_001528_859957_689F03EB X-CRM114-Status: GOOD ( 21.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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.