在 2026/10/12 14:48, Naman Jain 写道: > > > On 10/9/2026 5:06 PM, Fengnan wrote: >> Hi Naman: >> >> This is an issue I hadn’t noticed before. >> I'll take a closer look at this issue later. >> >> Regarding testing, there are a few points to note: >> 1. My patch has been updated to V2, >> https://lore.kernel.org/linux-nvme/[email protected]/ >> 2. In my experience, when do performance tests, it’s best to do precondition >> first and then execute an ABBA test; this ensures reliable results. >> 3. IIRC, disabling interrupts in the QEMU kernel does not actually disable >> hardware >> interrupts; QEMU still handles them, which has a significant impact on >> performance testing. >> Perhaps you could test this on a physical machine. >> >> Also, I’d like to ask: does this softlockup issue only occur on QEMU+ARM? >> or does it also occur on x86 physical machines? >> Have you tried enabling the “Posted Interrupt” feature in VM? Maybe this >> will solve >> this problem in VM. >> >> Thanks. > > Hi Fengnan, > Thanks for the suggestion. > > I was using QEMU just for sanity, all the test results are based on > experiments in an Azure ARM64 Hyper-V VM. I could not create enough load on > my local QEMU VM to cause a lockup, so I am relying only on the Azure VM I > have. I would not rule out x86 for this issue, as we have seen spurious > lockups in the fleet, which are more common on certain SKUs, but my current > experiments are limited to arm64. The proposed solution should solve it for > both.
I set up a test environment on my own this morning. Although I wasn't able to reproduce the soft lockup issue, I did observe I/O latency of several hundred milliseconds. > > The guest exposes a GICv3 CPU interface and Hyper-V vPCI maps the NVMe MSI-X > vectors as guest GIC SPIs. I do not see an ITS, LPIs/vLPIs, GICv4 VPEs, or > another direct virtual interrupt injection interface exposed to the guest. > Also, posted/direct interrupts would reduce host-to-guest interrupt injection > overhead, but the lockup here occurs after delivery, while nvme_irq() > repeatedly drains completion queues in guest hardirq context. So I would not > expect posted interrupts alone to provide the missing scheduling boundary. I'm thinking that adding a scheduling check to my patch should also resolve this issue. That would be simpler and more acceptable, we can work together to refine it. Thanks. > > Thanks, > Naman
