On 7/14/26 5:43 AM, Simon Horman wrote:
On Mon, Jul 06, 2026 at 12:35:53PM -0700, Mingming Cao wrote:
Queue 0 and subordinate RX queues use different interrupt control
interfaces in PHYP:
- queue 0: h_vio_signal() after h_register_logical_lan()
- queue N: H_VIOCTL against the queue handle/hwirq mapping
The current code is single-queue oriented and cannot safely scale to
multiple RX queues in poll completion and open/close IRQ setup.
Introduce queue-indexed interrupt helpers:
ibmveth_enable_irq(adapter, queue_index)
ibmveth_disable_irq(adapter, queue_index)
ibmveth_setup_rx_interrupts()
ibmveth_cleanup_rx_interrupts()
These helpers centralize queue0-vs-subordinate dispatch and make IRQ
lifecycle symmetric across open/close and future resize paths.
request_irq() is wired with &adapter->napi[i] as dev_id per queue, so
interrupt ownership follows the NAPI instance that services that RX
queue.
Signed-off-by: Mingming Cao<[email protected]>
Reviewed-by: Dave Marquardt<[email protected]>
*
Hi Simon,
Thanks for the thorough review to the entire series!
*
Although it is added later in this patch set, I believe linux/irqdomain.h
needs to be included in this patch so that irq_dispose_mapping is defined.
*
Thanks, will fix in v4 — move linux/irqdomain.h into this patch
where irq_dispose_mapping() is first used.
*
Also, I think it would be best to add these helpers in the same patch(es)
that they are first used. As this will avoid temporal compiler warnings
about declared but otherwise unused functions. Similarly for patch 13/15.
*
Agreed. In v4 I will introduce each helper in the same patch that
first calls it from open()/close() (and the same rule for resize /
set_channels), move linux/irqdomain.h with the first
irq_dispose_mapping() use, and open()/close() will be converted
incrementally; there
will not be a separate MQ-only open path before multi_queue is enabled
*
Overall, please make sure that when each patch of the series is applied
no new warnings or errors are introduced for allmodconfig W=1 builds.
FWIIW, I exercised this using gcc 16.1 from
https://www.kernel.org/pub/tools/crosstool/
...
**
*Will do — v4 will be checked so each patch applies cleanly under*
*
allmodconfig W=1 (no new warnings/errors), including with a
current crosstool gcc.
*
*
Thanks,
Mingming
*
