8724a18868
config handling stack overflow 55a62eb0-xl-correct-handling-of-extra_config-in-main_cpupoolcreate.patch - bsc#907514 - Bus fatal error & sles12 sudden reboot has been observed - bsc#910258 - SLES12 Xen host crashes with FATAL NMI after shutdown of guest with VT-d NIC - bsc#918984 - Bus fatal error & sles11-SP4 sudden reboot has been observed - bsc#923967 - Partner-L3: Bus fatal error & sles11-SP3 sudden reboot has been observed 552d293b-x86-vMSI-X-honor-all-mask-requests.patch 552d2966-x86-vMSI-X-add-valid-bits-for-read-acceleration.patch 5576f143-x86-adjust-PV-I-O-emulation-functions-types.patch 55795a52-x86-vMSI-X-support-qword-MMIO-access.patch 5583d9c5-x86-MSI-X-cleanup.patch 5583da09-x86-MSI-track-host-and-guest-masking-separately.patch 55b0a218-x86-PCI-CFG-write-intercept.patch 55b0a255-x86-MSI-X-maskall.patch 55b0a283-x86-MSI-X-teardown.patch 55b0a2ab-x86-MSI-X-enable.patch 55b0a2db-x86-MSI-track-guest-masking.patch - Upstream patches from Jan 552d0f49-x86-traps-identify-the-vcpu-in-context-when-dumping-regs.patch 559bc633-x86-cpupool-clear-proper-cpu_valid-bit-on-CPU-teardown.patch 559bc64e-credit1-properly-deal-with-CPUs-not-in-any-pool.patch 559bc87f-x86-hvmloader-avoid-data-corruption-with-xenstore-rw.patch 55a66a1e-make-rangeset_report_ranges-report-all-ranges.patch 55a77e4f-dmar-device-scope-mem-leak-fix.patch OBS-URL: https://build.opensuse.org/package/show/Virtualization/xen?expand=0&rev=373
47 lines
1.9 KiB
Diff
47 lines
1.9 KiB
Diff
References: bsc#907514 bsc#910258 bsc#918984 bsc#923967
|
|
|
|
# Commit 70a3cbb8c9cb17a61fa25c48ba3d7b44fd059c90
|
|
# Date 2015-04-14 16:50:35 +0200
|
|
# Author Jan Beulich <jbeulich@suse.com>
|
|
# Committer Jan Beulich <jbeulich@suse.com>
|
|
x86/vMSI-X: honor all mask requests
|
|
|
|
Commit 74fd0036de ("x86: properly handle MSI-X unmask operation from
|
|
guests") didn't go far enough: it fixed an issue with unmasking, but
|
|
left an issue with masking in place: Due to the (late) point in time
|
|
when qemu requests the hypervisor to set up MSI-X interrupts (which is
|
|
where the MMIO intercept gets put in place), the hypervisor doesn't
|
|
see all guest writes, and hence shouldn't make assumptions on the state
|
|
the virtual MSI-X resources are in. Bypassing the rest of the logic on
|
|
a guest mask operation leads to
|
|
|
|
[00:04.0] pci_msix_write: Error: Can't update msix entry 1 since MSI-X is already enabled.
|
|
|
|
which surprisingly enough doesn't lead to the device not working
|
|
anymore (I didn't dig in deep enough to figure out why that is). But it
|
|
does prevent the IRQ to be migrated inside the guest, i.e. all
|
|
interrupts will always arrive in vCPU 0.
|
|
|
|
Signed-off-by: Jan Beulich <jbeulich@suse.com>
|
|
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
|
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
|
|
|
|
--- a/xen/arch/x86/hvm/vmsi.c
|
|
+++ b/xen/arch/x86/hvm/vmsi.c
|
|
@@ -286,11 +286,11 @@ static int msixtbl_write(struct vcpu *v,
|
|
goto out;
|
|
}
|
|
|
|
- /* exit to device model if address/data has been modified */
|
|
- if ( test_and_clear_bit(nr_entry, &entry->table_flags) )
|
|
+ /* Exit to device model when unmasking and address/data got modified. */
|
|
+ if ( !(val & PCI_MSIX_VECTOR_BITMASK) &&
|
|
+ test_and_clear_bit(nr_entry, &entry->table_flags) )
|
|
{
|
|
- if ( !(val & PCI_MSIX_VECTOR_BITMASK) )
|
|
- v->arch.hvm_vcpu.hvm_io.msix_unmask_address = address;
|
|
+ v->arch.hvm_vcpu.hvm_io.msix_unmask_address = address;
|
|
goto out;
|
|
}
|
|
|