phb3: Lock the PHB on set_xive callbacks

Those are called by the interrupts core and thus skip the locking
implicit in the PCI opal calls.

However IODA table access can be racy, so make sure we lock the PHB.

Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
(cherry picked from commit 55af871041a4b09e53013671450980bdb36f91e3)
[stewart@linux.vnet.ibm.com: backport to phb3_lock()]
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>

1 files changed, 8 insertions, 0 deletions

diff --git a/hw/phb3.c b/hw/phb3.c
index b200aea..828353d 100644
--- a/hw/phb3.c
+++ b/hw/phb3.c
@@ -1627,6 +1627,8 @@ static int64_t phb3_msi_set_xive(void *data,
 	    ive_num > PHB3_MSI_IRQ_MAX)
 		return OPAL_PARAMETER;
 
+	phb3_lock(&p->phb);
+
 	/*
 	 * We need strip the link from server. As Milton told
 	 * me, the server is assigned as follows and the left
@@ -1688,6 +1690,8 @@ static int64_t phb3_msi_set_xive(void *data,
 		out_be64(p->regs + PHB_IVC_UPDATE, ivc);
 	}
 
+	phb3_unlock(&p->phb);
+
 	return OPAL_SUCCESS;
 }
 
@@ -1742,6 +1746,8 @@ static int64_t phb3_lsi_set_xive(void *data,
 	lxive = SETFIELD(IODA2_LXIVT_SERVER, 0ul, server);
 	lxive = SETFIELD(IODA2_LXIVT_PRIORITY, lxive, prio);
 
+	phb3_lock(&p->phb);
+
 	/*
 	 * We cache the arguments because we have to mangle
 	 * it in order to hijack 3 bits of priority to extend
@@ -1757,6 +1763,8 @@ static int64_t phb3_lsi_set_xive(void *data,
 	lxive = SETFIELD(IODA2_LXIVT_PRIORITY, lxive, prio);
 	out_be64(p->regs + PHB_IODA_DATA0, lxive);
 
+	phb3_unlock(&p->phb);
+
 	return OPAL_SUCCESS;
 }