config handling stack overflow CVE-2015-3259-xsa137.patch - Upstream patches from Jan 558bfaa0-x86-traps-avoid-using-current-too-early.patch 5592a116-nested-EPT-fix-the-handling-of-nested-EPT.patch 559b9dd6-x86-p2m-ept-don-t-unmap-in-use-EPT-pagetable.patch 559bdde5-pull-in-latest-linux-earlycpio.patch - Upstream patches from Jan pending review 552d0fd2-x86-hvm-don-t-include-asm-spinlock-h.patch 552d0fe8-x86-mtrr-include-asm-atomic.h.patch 552d293b-x86-vMSI-X-honor-all-mask-requests.patch 552d2966-x86-vMSI-X-add-valid-bits-for-read-acceleration.patch 554c7aee-x86-provide-arch_fetch_and_add.patch 554c7b00-arm-provide-arch_fetch_and_add.patch 55534b0a-x86-provide-add_sized.patch 55534b25-arm-provide-add_sized.patch 5555a4f8-use-ticket-locks-for-spin-locks.patch 5555a5b9-x86-arm-remove-asm-spinlock-h.patch 5555a8ec-introduce-non-contiguous-allocation.patch 55795a52-x86-vMSI-X-support-qword-MMIO-access.patch 557eb55f-gnttab-per-active-entry-locking.patch 557eb5b6-gnttab-introduce-maptrack-lock.patch 557eb620-gnttab-make-the-grant-table-lock-a-read-write-lock.patch 557ffab8-evtchn-factor-out-freeing-an-event-channel.patch 5582bf43-evtchn-simplify-port_is_valid.patch 5582bf81-evtchn-remove-the-locking-when-unmasking-an-event-channel.patch 5583d9c5-x86-MSI-X-cleanup.patch 5583da09-x86-MSI-track-host-and-guest-masking-separately.patch 5583da64-gnttab-use-per-VCPU-maptrack-free-lists.patch OBS-URL: https://build.opensuse.org/package/show/Virtualization/xen?expand=0&rev=369
45 lines
1.9 KiB
Diff
45 lines
1.9 KiB
Diff
# 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>
|
|
|
|
--- sle12sp1.orig/xen/arch/x86/hvm/vmsi.c 2015-07-08 11:22:13.000000000 +0200
|
|
+++ sle12sp1/xen/arch/x86/hvm/vmsi.c 2015-04-20 09:30:29.000000000 +0200
|
|
@@ -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;
|
|
}
|
|
|