From e97391ae2bb5a146a5041453f9185326654264d9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= Date: Thu, 5 Sep 2019 17:59:10 +0200 Subject: [PATCH] xive: fix return value of opal_xive_allocate_irq() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When the maximum number of interrupts per chip is reached, xive_try_allocate_irq() returns an internal XIVE error: XIVE_ALLOC_NO_SPACE. But its value 0xffffffff is interpreted as a positive value by its caller opal_xive_allocate_irq() and not as an error. opal_xive_allocate_irq() returns this value to Linux which also considers 0xffffffff as a valid interrupt number and tries to get the interrupt characteritics using opal_xive_get_irq_info(). This OPAL calls finally fails leading to all sort of errors on the host which is not prepared for such a scenario. Code impacted are the IPI setup and the both XIVE KVM devices. Fix by returning OPAL_RESOURCE from xive_try_allocate_irq() which is consistent with the other errors returned by this routine. This fixes the behavior in opal_xive_allocate_irq() and in Linux. A workaround could be introduced in Linux to consider 0xffffffff as a OPAL_RESOURCE value. This assumption is valid with the current XIVE IRQ number encoding. Fixes: 07946e68f47a ("xive: Add interrupt allocator") Reported-by: Greg Kurz Signed-off-by: Cédric Le Goater [oliver: Added fixes tag] Signed-off-by: Oliver O'Halloran --- hw/xive.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/xive.c b/hw/xive.c index 76b41a9ee95f..5dc66598ee12 100644 --- a/hw/xive.c +++ b/hw/xive.c @@ -5059,7 +5059,7 @@ static int64_t xive_try_allocate_irq(struct xive *x) idx = bitmap_find_zero_bit(*x->ipi_alloc_map, base_idx, max_count); if (idx < 0) { unlock(&x->lock); - return XIVE_ALLOC_NO_SPACE; + return OPAL_RESOURCE; } bitmap_set_bit(*x->ipi_alloc_map, idx); girq = x->int_base + idx;