diff mbox

[1/3] PCI/MSI: Initial hook for archs to declare multivector MSI support

Message ID 20141121220833.31095.12371.stgit@gimli.home (mailing list archive)
State New, archived
Delegated to: Bjorn Helgaas
Headers show

Commit Message

Alex Williamson Nov. 21, 2014, 10:08 p.m. UTC
For the most part multivector MSI is not supported and drivers and
hardware wanting multiple vectors opt for MSI-X instead.  It seems
though that having the ability to query the arch/platform code to
determine whether allocating multiple MSI vectors will ever succeed
is a useful thing.  For instance, vfio-pci can use this to determine
whether to expose multiple MSI vectors to the user.  If we know we
cannot ever support more than one vector, we have a better shot at
the userspace driver working, especially if it's a guest OS, if we
only expose one vector as being available in the interface.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---

 drivers/pci/msi.c   |    5 +++++
 include/linux/msi.h |    1 +
 2 files changed, 6 insertions(+)


--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Thomas Gleixner Nov. 23, 2014, 8:20 p.m. UTC | #1
On Fri, 21 Nov 2014, Alex Williamson wrote:
> For the most part multivector MSI is not supported and drivers and
> hardware wanting multiple vectors opt for MSI-X instead.  It seems
> though that having the ability to query the arch/platform code to
> determine whether allocating multiple MSI vectors will ever succeed
> is a useful thing.  For instance, vfio-pci can use this to determine
> whether to expose multiple MSI vectors to the user.  If we know we
> cannot ever support more than one vector, we have a better shot at
> the userspace driver working, especially if it's a guest OS, if we
> only expose one vector as being available in the interface.
> 
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> ---
> 
>  drivers/pci/msi.c   |    5 +++++
>  include/linux/msi.h |    1 +
>  2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 9fab30a..36b503a 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -79,6 +79,11 @@ int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
>  	return 0;
>  }
>  
> +bool __weak arch_supports_multivector_msi(struct pci_dev *dev)

Please not another weak arch function. We are in the process to reduce
them not to extend them.

arch_supports is pretty much wrong here anyway. We are moving away
from arch MSI dependencies simply because it's not a arch property per
se.

Multi MSI is a property of the underlying interrupt controllers and
there might be several MSI interrupt domains on a given system. They
can or cannot support multi MSI.

The current x86 implementation is a tangled maze and Jiang is in the
process to distangle it completely. Until thats done x86 is not going
to add new ad hoc interfaces.

Once we converted everything over to the new hierarchical irqdomains
we can add such an interface to the code, but for now I'm not
accepting anything like that into x86 msi related code.

Thanks,

	tglx



--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Alex Williamson Nov. 24, 2014, 9:45 p.m. UTC | #2
On Sun, 2014-11-23 at 21:20 +0100, Thomas Gleixner wrote:
> On Fri, 21 Nov 2014, Alex Williamson wrote:
> > For the most part multivector MSI is not supported and drivers and
> > hardware wanting multiple vectors opt for MSI-X instead.  It seems
> > though that having the ability to query the arch/platform code to
> > determine whether allocating multiple MSI vectors will ever succeed
> > is a useful thing.  For instance, vfio-pci can use this to determine
> > whether to expose multiple MSI vectors to the user.  If we know we
> > cannot ever support more than one vector, we have a better shot at
> > the userspace driver working, especially if it's a guest OS, if we
> > only expose one vector as being available in the interface.
> > 
> > Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> > ---
> > 
> >  drivers/pci/msi.c   |    5 +++++
> >  include/linux/msi.h |    1 +
> >  2 files changed, 6 insertions(+)
> > 
> > diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> > index 9fab30a..36b503a 100644
> > --- a/drivers/pci/msi.c
> > +++ b/drivers/pci/msi.c
> > @@ -79,6 +79,11 @@ int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> >  	return 0;
> >  }
> >  
> > +bool __weak arch_supports_multivector_msi(struct pci_dev *dev)
> 
> Please not another weak arch function. We are in the process to reduce
> them not to extend them.
> 
> arch_supports is pretty much wrong here anyway. We are moving away
> from arch MSI dependencies simply because it's not a arch property per
> se.
> 
> Multi MSI is a property of the underlying interrupt controllers and
> there might be several MSI interrupt domains on a given system. They
> can or cannot support multi MSI.
> 
> The current x86 implementation is a tangled maze and Jiang is in the
> process to distangle it completely. Until thats done x86 is not going
> to add new ad hoc interfaces.
> 
> Once we converted everything over to the new hierarchical irqdomains
> we can add such an interface to the code, but for now I'm not
> accepting anything like that into x86 msi related code.

Ok, I guess I can do some ugliness with associating the IOMMU IRQ
remapping capability with multivector MSI support within an #ifdef x86
block.  Gross, but I think that's as accurate as I can get w/o a hook
through the MSI code.  Is there any target for the refactoring you
mention?  Thanks,

Alex


--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jiang Liu Nov. 25, 2014, 3:22 a.m. UTC | #3
On 2014/11/25 5:45, Alex Williamson wrote:
> On Sun, 2014-11-23 at 21:20 +0100, Thomas Gleixner wrote:
>> On Fri, 21 Nov 2014, Alex Williamson wrote:
>>> For the most part multivector MSI is not supported and drivers and
>>> hardware wanting multiple vectors opt for MSI-X instead.  It seems
>>> though that having the ability to query the arch/platform code to
>>> determine whether allocating multiple MSI vectors will ever succeed
>>> is a useful thing.  For instance, vfio-pci can use this to determine
>>> whether to expose multiple MSI vectors to the user.  If we know we
>>> cannot ever support more than one vector, we have a better shot at
>>> the userspace driver working, especially if it's a guest OS, if we
>>> only expose one vector as being available in the interface.
>>>
>>> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
>>> ---
>>>
>>>  drivers/pci/msi.c   |    5 +++++
>>>  include/linux/msi.h |    1 +
>>>  2 files changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
>>> index 9fab30a..36b503a 100644
>>> --- a/drivers/pci/msi.c
>>> +++ b/drivers/pci/msi.c
>>> @@ -79,6 +79,11 @@ int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
>>>  	return 0;
>>>  }
>>>  
>>> +bool __weak arch_supports_multivector_msi(struct pci_dev *dev)
>>
>> Please not another weak arch function. We are in the process to reduce
>> them not to extend them.
>>
>> arch_supports is pretty much wrong here anyway. We are moving away
>> from arch MSI dependencies simply because it's not a arch property per
>> se.
>>
>> Multi MSI is a property of the underlying interrupt controllers and
>> there might be several MSI interrupt domains on a given system. They
>> can or cannot support multi MSI.
>>
>> The current x86 implementation is a tangled maze and Jiang is in the
>> process to distangle it completely. Until thats done x86 is not going
>> to add new ad hoc interfaces.
>>
>> Once we converted everything over to the new hierarchical irqdomains
>> we can add such an interface to the code, but for now I'm not
>> accepting anything like that into x86 msi related code.
> 
> Ok, I guess I can do some ugliness with associating the IOMMU IRQ
> remapping capability with multivector MSI support within an #ifdef x86
> block.  Gross, but I think that's as accurate as I can get w/o a hook
> through the MSI code.  Is there any target for the refactoring you
> mention?  Thanks,
Hi Alex,
	The hierarchy irqdomain framework and some preparation work
for PCI MSI refactor will be merged into v3.19, there are already in
tip tree. If thing goes smoothly, we may finish PCI MSI refactoring
on x86 platform for the merging window after 3.19, not sure 3.20 or
4.0:)
Regards!
Gerry
> 
> Alex
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 9fab30a..36b503a 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -79,6 +79,11 @@  int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 	return 0;
 }
 
+bool __weak arch_supports_multivector_msi(struct pci_dev *dev)
+{
+	return false;
+}
+
 /*
  * We have a default implementation available as a separate non-weak
  * function, as it is used by the Xen x86 PCI code
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 44f4746..2365c64 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -58,6 +58,7 @@  void arch_teardown_msi_irq(unsigned int irq);
 int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
 void arch_teardown_msi_irqs(struct pci_dev *dev);
 void arch_restore_msi_irqs(struct pci_dev *dev);
+bool arch_supports_multivector_msi(struct pci_dev *dev);
 
 void default_teardown_msi_irqs(struct pci_dev *dev);
 void default_restore_msi_irqs(struct pci_dev *dev);