[Xen-changelog] [xen master] x86/MSI-X: correctly track interrupt masking state

[patchbot@xxxxxxx]

commit bd6ad54403019f213e18791b9856e4b7b71a4d47
Author:     Jan Beulich <jbeulich@xxxxxxxx>
AuthorDate: Mon Apr 25 14:23:07 2016 +0200
Commit:     Jan Beulich <jbeulich@xxxxxxxx>
CommitDate: Mon Apr 25 14:23:07 2016 +0200

    x86/MSI-X: correctly track interrupt masking state
    
    When a guest unmasks MSI-X interrupts before enabling MSI-X on the
    device, so far nothing updates the {host,guest}_masked internal state;
    this to date only gets done when MSI-X is already enabled. This is why
    half way recent Linux works (as it enables MSI-X first), while Windows
    doesn't (as it enables MSI-X only after having set up und unmasked all
    vectors). Since with a successful write to the vector control field
    everything is ready internally, we should also update internal tracking
    state there, regardless of the device's MSI-X enabled state.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
---
 xen/arch/x86/msi.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
index a46dcf7..8d64ee2 100644
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -434,8 +434,13 @@ static bool_t msi_set_mask_bit(struct irq_desc *desc, 
bool_t host, bool_t guest)
         {
             writel(flag, entry->mask_base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
             readl(entry->mask_base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
+
             if ( likely(control & PCI_MSIX_FLAGS_ENABLE) )
                 break;
+
+            entry->msi_attrib.host_masked = host;
+            entry->msi_attrib.guest_masked = guest;
+
             flag = 1;
         }
         else if ( flag && !(control & PCI_MSIX_FLAGS_MASKALL) )
--
generated by git-patchbot for /home/xen/git/xen.git#master

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog