aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorKeir Fraser <keir.fraser@citrix.com>2010-03-25 09:19:33 +0000
committerKeir Fraser <keir.fraser@citrix.com>2010-03-25 09:19:33 +0000
commit5fead6d6759d83cd1924534ef303c9eccb97ba3a (patch)
treedf55e754f2327d5bee8b49af58e230328bc4cc4d
parent7b203cca89af0d7599ba3e9798d5102dcd1874a8 (diff)
downloadxen-5fead6d6759d83cd1924534ef303c9eccb97ba3a.tar.gz
xen-5fead6d6759d83cd1924534ef303c9eccb97ba3a.tar.bz2
xen-5fead6d6759d83cd1924534ef303c9eccb97ba3a.zip
x86: s3: write_msi_msg: entry->msg should be in the compatibility format
When Interrupt Remapping is used, after Dom0 S3, Dom0's filesystem might become inaccessible as the SATA disk's MSI interrupt becomes buggy. The cause is: After set_msi_affinity() or setup_msi_irq() invokes write_msi_msg(), entry->msg records the remappable format message; during S3 resume, Dom0 invokes the PHYSDEVOP_restore_msi hypercall to restore the MSI registers of devices, and in pci_restore_msi_state() -> write_msi_msg(), the 'entry->msg' of remappable format is passed, but in write_msi_msg() -> ... -> msi_msg_to_remap_entry(), the 'msg' is assumed to be in compatibility format. As a result, after s3, the IRTE is corrupted. Actually the only users of 'entry->msg' are pci_restore_msi_state() and dump_msi(). That's why we don't have issue except Dom0 S3. Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
-rw-r--r--xen/arch/x86/msi.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
index 06b53a202f..5b8037a6f9 100644
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -218,6 +218,8 @@ static int set_irq_msi(struct msi_desc *entry)
static void write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
{
+ entry->msg = *msg;
+
if ( iommu_enabled )
iommu_update_ire_from_msi(entry, msg);
@@ -260,7 +262,6 @@ static void write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
default:
BUG();
}
- entry->msg = *msg;
}
void set_msi_affinity(unsigned int irq, cpumask_t mask)