Question: Help understanding control queue interrupt configuration

[zjmletang]

Hi team,

I'm studying the NetKVM control queue implementation and noticed something I don't fully understand. I'd appreciate any insight from the community.

Current behavior

The control queue (CXPath) configures both:

1. Config change interrupt - triggers on link state changes, device reset, etc.
2. Queue interrupt - triggers when control queue buffers are processed

What I observed

All control operations (SendControlMessage) appear to use synchronous polling:

m_VirtQueue.AddBuf(...);
m_VirtQueue.Kick();

// Poll for response
p = m_VirtQueue.GetBuf(&len);
for (int i = 0; i < 600000 && !p; ++i) {
NdisStallExecution(5);
p = m_VirtQueue.GetBuf(&len);
}And the DPC handler (ParaNdis_CXDPCWorkBody) only reads from config space, not from the control queue itself.

My confusion

Since control messages already poll for responses synchronously, the queue interrupt seems to trigger unnecessarily:

• When a control message completes, the queue interrupt fires
• A DPC is scheduled and executed
• But the DPC doesn't actually process the queue data (no GetBuf() call)
• Meanwhile, the sender thread already got the response via polling

This creates spurious interrupts and DPC overhead. While control operations are infrequent so the performance impact is likely negligible, it still seems suboptimal.

Question

What am I missing? Is there a scenario where:

• Control queue operates asynchronously?
• The queue interrupt is needed for proper virtio protocol behavior?
• Some edge case or future functionality requires it?

Or could this be simplified to only configure the config change interrupt, avoiding the unnecessary queue interrupts?

Thanks for any guidance!

[YanVugenfirer]

Hi @zjmletang,

I think CQ is implemented a way it is mostly due to historical reasons. Probably copy paste from the first driver that needed it (virtio-serial, but I might be mistaken).

Latest changes in CQ handing: https://github.com/virtio-win/kvm-guest-drivers-windows/pull/1353/commits

1. We don't have implementation that works asynchronously
2. It is nice to have, but we were OK without it until now. I agree that interrupts for CQ should be turned off.
3. Could be, but it is hard to see which one until we encounter it.

If you have propositions for different handling, let's discuss.

Best regards,
Yan.

[zjmletang]

hi @YanVugenfirer

Thanks a lot, that makes sense to me now.

As a first step, I think we can safely disable the CQ interrupt to avoid the extra, unnecessary interrupt handling.

I’m also wondering whether, in the future, it would make sense to factor the config‑handling logic into a separate class (e.g. CParaNdisConfigInterrupt), extracting that responsibility from CParaNdisCX so that CParaNdisCX can focus only on CQ handling.

I realize these changes are unlikely to bring any real performance improvements, and for a mature driver like netkvm I’m not sure whether such refactoring is worthwhile now, or if it would be better to wait and do it together with any future protocol changes.

[YanVugenfirer]

@zjmletang I agree that such separation make sense. But I suggest to wait.