From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 E4CB2149DF1 for ; Sat, 11 Jul 2026 20:37:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783802254; cv=none; b=ldbvhHeYRD3DtbmG1Yk2f5ETkqX0ZejNA0FYhEa1JEpphKenEYlRBtqqLodetP+3SqA7fNa5hw9dCKcSo6p2nhAoS3JnDoy0GaxC1tqiR2vfKvy7eMI4bz02oKfOhSxtbGW1gKnfM5o+URvVd1lsdgLg/ALJT9MychGRSXUPpOI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783802254; c=relaxed/simple; bh=vNxx2CXg4XDt7KBfNxwUYWz36O6LuY/p4VJKVoSzN6c=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=lu7FRoNbjMEpb7Pc1h6xOmwS+OBgpO3LrfbduYSKCzK2ql7puL+U3CHdyYEyA6MAZgE0WbtOwMdt14eh4C5YV2pz+4bGwQWfXQX7wgkGy1nBDu1BwKV7lDE1216m2zE6T8G5Tm53RQ1khvNHND0m99CV2E/XDhNAZmDjuLhsx2I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=I61qDaH1; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="I61qDaH1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 189341F000E9; Sat, 11 Jul 2026 20:37:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783802252; bh=h3/dT7fVjuGjsbWgOZgOtPP4PWvx3UD0bx0HBuFb9KY=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=I61qDaH1wGQpS///KPcrExYUG0Ejv7PBV1iAfYBwBG3HG6tDnlDoHOPgUER76gsPy TLydrkw4vGJCHO849+xeFo5W6uVhcpYgNY16iPlgZFZ9V3P11/AuJ66bBgxIO2FxGr ZOHw0cXZxABA0o2vg+3m5yy1gFcgPEVDbsmIYN59cqPOvKPoLaiGmHM1Dci09goU3x uJoefZoQ8Zhgeuefp7RW63bn+qpxRDirfYwrJejk8sBScbOJBtXqLIkO8caxggrDiO MesSLW7hs3GHf7kbgPL0H1EpkcrgprEBbrcYvGxWH1qrDq1owAJzZb4d4IIS5pgU74 ynXXvihXHss9Q== From: Thomas Gleixner To: Jinqian Yang , lpieralisi@kernel.org, maz@kernel.org, alex@shazbot.org Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, liuyonglong@huawei.com, wangzhou1@hisilicon.com, linuxarm@huawei.com, Jinqian Yang Subject: Re: [RFC PATCH v2] irqchip/gic-v3-its: enable dynamic MSI-X allocation In-Reply-To: <20260711022015.3049867-1-yangjinqian1@huawei.com> References: <20260711022015.3049867-1-yangjinqian1@huawei.com> Date: Sat, 11 Jul 2026 22:37:30 +0200 Message-ID: <877bn1qn3p.ffs@fw13> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Sat, Jul 11 2026 at 10:20, Jinqian Yang wrote: > On ARM64 platforms with GICv3 ITS, VFIO PCI passthrough currently > cannot dynamically allocate MSI-X vectors after MSI-X has been > enabled. When QEMU needs to extend the vector range, it must > disable MSI-X, free all interrupts, then re-enable with a larger > allocation. This creates an interrupt loss window for already-active > vectors. > > Consider HNS3 with RoCE: NIC and RDMA share one PCI device and > ITS DeviceID, with MSI-X vectors partitioned as NIC (lower range) > then RoCE (starting at base_vector = num_nic_msi). In VFIO > passthrough, loading hns_roce after hns3 forces QEMU to tear down > all interrupts before re-allocating the larger range. During this > process, NIC interrupts may be lost. Testing confirmed that this > occasionally occurs, causing the network port reset to fail. This > appears to be unavoidable, as it's a standard approach adopted by > all network card vendors. > > On Hisilicon HIP09 (ARM64, GICv3/GICv4.1) with latest upstream kernel > and QEMU 8.2. VFIO passthrough of HNS3 NIC to VM: load both hns3 and > hns_roce_hw_v2 drivers and trigger FLR, this bug will occur occasionally. > After enabling dynamic MSIX allocation, this bug no longer occurs. > > Signed-off-by: Jinqian Yang > --- > Changes in v2: > - Updated the commit message to add test information. Well, it contains test information, but it does not tell me _WHY_ this is safe to do, i.e. what makes gic-v3-its eligible to set this flag?