This was the original attempt to address XSA-467, until it was found
that IRQs can be off already from higher up the call stack. Nevertheless
moving code out of locked regions is generally desirable anyway; some of
the callers, after all, don't disable interrupts or acquire other locks.
Hence, despite this not addressing the original report:
Data collection solely depends on the passed in PCI device. Furthermore,
since the function only writes to a local variable, we can pull the
invocation of set_msi_source_id() (and also set_hpet_source_id()) ahead
of the acquiring of the (IRQ-safe) lock.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Roger Pau Monné <roger....@citrix.com>
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -508,6 +508,11 @@ static int msi_msg_to_remap_entry(
const struct pi_desc *pi_desc = msi_desc->pi_desc;
bool alloc = false;
+ if ( pdev )
+ set_msi_source_id(pdev, &new_ire);
+ else
+ set_hpet_source_id(msi_desc->hpet_id, &new_ire);
+
if ( msi_desc->msi_attrib.type == PCI_CAP_ID_MSI )
nr = msi_desc->msi.nvec;
@@ -575,11 +580,6 @@ static int msi_msg_to_remap_entry(
new_ire.post.p = 1;
}
- if ( pdev )
- set_msi_source_id(pdev, &new_ire);
- else
- set_hpet_source_id(msi_desc->hpet_id, &new_ire);
-
/* now construct new MSI/MSI-X rte entry */
remap_rte = (struct msi_msg_remap_entry *)msg;
remap_rte->address_lo.dontcare = 0;
