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 9B62ECD98F6 for ; Thu, 18 Jun 2026 06:33:33 +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-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc: To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=fxEPUDJEb/E2TNBGBdy1DqfUWhcoKOjLbBcYOBP7BPY=; b=mO0wWx8dSOWhMWHBkd95fXPQdl 3y7qEq9ernYf4zzSFWvxnjFUiEOH8VOOXyGtOZoLQ+hJYLZH6xoRtbiUrK3Ri0aGdcdhhm/M5VZ7V 73OH2ZcXUzcC2ekpZL7XmBs91nM4dp66LeIVWaEE+OERvWhUA4OUqm7IV81nzINP0UZ7G77CI1nkg UYWtOA726qtD1pfaU4fPkr/6EI0BpqLiH8I0/OB0uhbPyyYW4khyiw+8Z7vXrjBJK6tg+iBEywyf0 VJmDlKoUMKarD7jKpxtqfHWBumlUgEIZc4mqIgu7E1OhMLWitBJ22BMp7aXeDZ2BfeqTnqwaHofTt VZDZTPqg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wa6Je-00000000hFI-0jZJ; Thu, 18 Jun 2026 06:33:30 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wa6Jb-00000000hES-1R2s for ath11k@lists.infradead.org; Thu, 18 Jun 2026 06:33:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1781764405; 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=fxEPUDJEb/E2TNBGBdy1DqfUWhcoKOjLbBcYOBP7BPY=; b=OPFkZDNunr/SnyD5u3QWFs10VAkHlQ1Lb3liWo8mVAErFdvqgxFQXGpEFNsMoSBIpr5O/Z coJR/vOnCVd8TYbwBi3b4tUiziJNWUQHleNywe3kd9LYTjGvO2ojZTf4qhakmSWIW6Bm9s GOOxcTnxnRcK1OF7+fmwZ0dO8wCyr8c= Received: from mx-prod-mc-01.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-220-sZX7nJgjPVaSpqNJyJkT1w-1; Thu, 18 Jun 2026 02:33:20 -0400 X-MC-Unique: sZX7nJgjPVaSpqNJyJkT1w-1 X-Mimecast-MFC-AGG-ID: sZX7nJgjPVaSpqNJyJkT1w_1781764399 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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 54C011955F0A; Thu, 18 Jun 2026 06:33:18 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.44.32.28]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 589073000238; Thu, 18 Jun 2026 06:33:13 +0000 (UTC) From: Jose Ignacio Tornos Martinez To: mani@kernel.org Cc: alex@shazbot.org, ath11k@lists.infradead.org, ath12k@lists.infradead.org, bhelgaas@google.com, jjohnson@kernel.org, jtornosm@redhat.com, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-wireless@vger.kernel.org, mhi@lists.linux.dev Subject: Re: [PATCH v9] PCI: Add device-specific reset for Qualcomm devices Date: Thu, 18 Jun 2026 08:33:08 +0200 Message-ID: <20260618063309.9536-1-jtornosm@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-MFC-PROC-ID: oOoNggQYTUAMXO2sTnHNVOSebK0Ju9HkZGa5MTqqubY_1781764399 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260617_233327_480778_35558362 X-CRM114-Status: GOOD ( 10.66 ) X-BeenThere: ath11k@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "ath11k" Errors-To: ath11k-bounces+ath11k=archiver.kernel.org@lists.infradead.org Hi Mani, Let me clarify the exact scenario and where the reset is necessary: * For the commented WiFi devices (WCN6855/WCN7850): Standard VFIO passthrough flow (this works fine): 1. Unbind native driver (ath11k/ath12k/MHI) 2. Bind vfio-pci driver 3. Assign device to VM 4. VM boots, loads its own driver → device works perfectly 5. VM shuts down cleanly → device can be reassigned → works fine The problem occurs with unclean VM termination: 1. VM crashes or is force-terminated 2. VFIO tries to reset the device before reassignment 3. Without a working PCI reset method, reset fails 4. Device stuck in undefined state → cannot be reassigned to another VM Unbinding the driver again doesn't help because the device hardware itself is in a bad state. From hypervisor: $ lspci -vvv -s 0000:03:00.0 03:00.0 Network controller: Qualcomm Technologies, Inc (rev ff) (prog-if ff) !!! Unknown header type 7f And a full host power-cycle is necessary to recover. * For the commented modem devices (SDX62/SDX65): Even worse because it fails during the first VM boot without proper reset capability, standard VFIO passthrough flow: 1. Unbind native driver (MHI) 2. Bind vfio-pci driver 3. Assign device to VM 4. VM boots, loads its own driver and crashes: [ 24.024165] mhi mhi0: Device failed to enter MHI Ready [ 24.024168] mhi mhi0: MHI did not enter READY state Unbind/rebind attempts fail: [ 352.643601] mhi mhi0: Requested to power ON [ 352.643611] mhi mhi0: Power on setup success [ 373.442954] mhi mhi0: Device failed to clear MHI Reset [ 373.442970] mhi mhi0: MHI did not enter READY state And requires a full host power cycle to recover, even outside of VFIO scenarios. * MHI Host driver's remove callback may handle clean software state teardown, but it doesn't provide a PCI reset capability that VFIO can invoke. VFIO needs a reset method registered in the PCI reset hierarchy (device_specific, pm, flr, bus, etc.). VFIO invokes this reset both during initial device binding (before the VM starts) and when reassigning the device between VMs - without a working reset method, the device cannot reach a clean state for initialization. I hope this clarifies the scenario better. Please let me know if I can provide more information or run any specific tests to help investigate this further. Thanks Best regards José Ignacio