On 02/27/2014 10:45 AM, Roger Pau Monné wrote:
@@ -291,7 +290,10 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, int nvec, int type) (pci_domain_nr(dev->bus) << 16); map_irq.devfn = dev->devfn; - if (type == PCI_CAP_ID_MSIX) { + if (type == PCI_CAP_ID_MSI && nvec > 1) { + map_irq.type = MAP_PIRQ_TYPE_MULTI_MSI; + map_irq.entry_nr = nvec; Are we overloading entry_nr here with a different meaning? I thought it was meant to be entry number (in MSI-X table for example), not number of entries.In the case of MSI message groups (MAP_PIRQ_TYPE_MULTI_MSI) entry_nr is the number of vectors to setup, so yes, it's an overloading of entry_nr.
Then I think we should at least make a note of this in physdev.h. (Or maybe even make entry_nr a union with nvec or some such, although that would look rather hacky).
....index 42721d1..eb13326d 100644 --- a/include/xen/interface/physdev.h +++ b/include/xen/interface/physdev.h @@ -131,6 +131,7 @@ struct physdev_irq { #define MAP_PIRQ_TYPE_GSI 0x1 #define MAP_PIRQ_TYPE_UNKNOWN 0x2 #define MAP_PIRQ_TYPE_MSI_SEG 0x3 +#define MAP_PIRQ_TYPE_MULTI_MSI 0x4 Formatting.I don't get the formatting problem, it's the same formatting that the other MAP_PIRQ_TYPE_* use, and if the patch is applied formatting is OK.
That's because my client messed up whitespaces. You can look for example at https://lkml.org/lkml/2014/2/26/352 to see the extra tab.
-boris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
