From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout03.his.huawei.com (canpmsgout03.his.huawei.com [113.46.200.218]) (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 33E1C449985 for ; Mon, 13 Jul 2026 07:01:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783926100; cv=none; b=oTl/JZ52KTK25pX10IdRf3+DjjjTLAqhGdTh4CDTa66Y6BoL41gz95SeUBmlu2J9Zja5cKYZNvm0lRIIrTdhU4BoPiCwbNf91jlLG+wOfKoI8noLMlExSwS6iRwsR3f55+saek8nCpypMfATjuB6+Y2lBfbZYgxlS6FOK00mOEw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783926100; c=relaxed/simple; bh=k/mwYxJJF/VXL25RNRPW3ETyz7MIIHuB66nrIWCjIB0=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=Qk8HN4NI/KAjHp573by1W0yZdnlYawuMc/GAUOy62fJSoZFvAnUEu8riVH7LCvsRXF4QED3cxxMsb+vMsxRKc/fSNbexQ7yIJZB9iLL26mDumr6RHamc1T77SEdJPyjySxjcsm0DHj0+oVakWrvkSHeR8WJkw4lvbZWDtCqbMyc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=JVNYHK2j; arc=none smtp.client-ip=113.46.200.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="JVNYHK2j" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=Fhg8pQ8rxXbZHFXoJmw5Fq/KeJI7fIRrrkp2ZTbbIvo=; b=JVNYHK2jM08UNaWD5mgvFDgWVj0oqRQaqI6AsuUKOAGybL66tYiDz8m/znesRDY4Rx98vheao OOpbjPtu6My1ESyoIlMLmgBZiR708ksX7q1z2arPOoFzNVKZqdg0c2zAA4GkiJ/S6N8nI69IIpT iuoWLDFfYLn3Pu7t+qCUNVQ= Received: from mail.maildlp.com (unknown [172.19.162.223]) by canpmsgout03.his.huawei.com (SkyGuard) with ESMTPS id 4gzCmr4fXNzpTHW; Mon, 13 Jul 2026 14:52:44 +0800 (CST) Received: from dggpemf500013.china.huawei.com (unknown [7.185.36.188]) by mail.maildlp.com (Postfix) with ESMTPS id 8132340561; Mon, 13 Jul 2026 15:01:33 +0800 (CST) Received: from [10.67.121.183] (10.67.121.183) by dggpemf500013.china.huawei.com (7.185.36.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 13 Jul 2026 15:01:32 +0800 Message-ID: <697a78bb-6cbf-4484-adfa-fdffe5bb0180@huawei.com> Date: Mon, 13 Jul 2026 15:01:32 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2] irqchip/gic-v3-its: enable dynamic MSI-X allocation To: Thomas Gleixner , , , CC: , , , , References: <20260711022015.3049867-1-yangjinqian1@huawei.com> <877bn1qn3p.ffs@fw13> From: Jinqian Yang In-Reply-To: <877bn1qn3p.ffs@fw13> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems200002.china.huawei.com (7.221.188.68) To dggpemf500013.china.huawei.com (7.185.36.188) Hi, On 2026/7/12 4:37, Thomas Gleixner wrote: > 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? Yes, the commit message should explain this. The GICv3 ITS is eligible because: When set this flag, for the ITT, adding a new vector only inserts a new entry, existing entries are untouched, so already-active vectors are unaffected. The ITT are sized to hwsize at MSI-X domain creation time. so there is always sufficient space for any vector index that may be dynamiclly allocated later. So the ITT never needs to be resized at runtime. The dynamic allocation path(msi_domain_alloc_irq_at -> populate_alloc_info) simply copies the pre-prepared alloc_data without re-invoking msi_prepare(). Then picking a free EventID from the already-allocated ITT and a free LPI form the already-reserved bitmap --- no existing vector is affected. I'll add this to the commit message in v3. Thanks, Jinqian