On 10/12/2026 12:30 PM, Fengnan wrote:
在 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.
Acked.
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.
Sure, happy to collaborate. Please include me in any new discussions you
have in your patch. And let's hear what Christoph and other maintainers
have to say, and then we can converge on that approach going forward.
Regards,
Naman
