Re: [RFC PATCH linux-2.6.18-xen] pciback: clean up (MSI-X vec, entrynr) list when resetting PCI device

[Paolo Bonzini <pbonzini@redhat.com>]

On 06/01/2011 04:59 PM, Jan Beulich wrote:
> The problem is that calling disable_msi_mode() alone is always a
> mistake, this should have been a static function just like its
> counterpart, enable_msi_mode().

MSI has been almost rewritten in the 2.6.21 timeframe, including along
the lines you wrote above:

commit b1cbf4e4dddd708ba268c3a2bf38383a269d490a
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Mon Mar 5 00:30:10 2007 -0800

    [PATCH] msi: fix up the msi enable/disable logic
    
    enable/disable_msi_mode have several side effects which keeps them from being
    generally useful.  So this patch replaces them with with two much more
    targeted functions: msi_set_enable and msix_set_enable.
    
    This patch makes pci_dev->msi_enabled and pci_dev->msix_enabled the definitive
    way to test if linux has enabled the msi capability, and has the appropriate
    msi data structures set up.

commit f5f2b13129a6541debf8851bae843cbbf48298b7
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Mon Mar 5 00:30:07 2007 -0800

    [PATCH] msi: sanely support hardware level msi disabling
    
    In some cases when we are not using msi we need a way to ensure that the
    hardware does not have an msi capability enabled.  Currently the code has been
    calling disable_msi_mode to try and achieve that.  However disable_msi_mode
    has several other side effects and is only available when msi support is
    compiled in so it isn't really appropriate.

commit 866a8c87c4e51046602387953bbef76992107bcb
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Sun Jan 28 12:45:54 2007 -0700

    msi: Fix msi_remove_pci_irq_vectors.
    
    Since msi_remove_pci_irq_vectors is designed to be called during
    hotplug remove it is actively wrong to query the hardware and expect
    meaningful results back.
    
    To that end remove the pci_find_capability calls.  Testing
    dev->msi_enabled and dev->msix_enabled gives us all of the information
    we need.

Probably the situation needs to be re-evaluated with all these applied to dom0.
There's some hope these apply to 2.6.18.

A simple "git log drivers/pci/msi.c" will show a few other patches that the
above might depend on (especially the locking changed).

Paolo