Provide the necessary constants for PCI/IMS support:
- A new bus token for MSI irqdomain identification
- A MSI feature flag for the MSI irqdomains to signal support
- A secondary domain id
The latter expands the device internal domain pointer storage array from 1
to 2 entries. That extra pointer is mostly unused today, but the
alternative solutions would not be free either and would introduce more
complexity all over the place. Trade the 8bytes for simplicity.
Signed-off-by: Thomas Gleixner <[email protected]>
---
include/linux/irqdomain_defs.h | 1 +
include/linux/msi.h | 2 ++
include/linux/msi_api.h | 1 +
3 files changed, 4 insertions(+)
--- a/include/linux/irqdomain_defs.h
+++ b/include/linux/irqdomain_defs.h
@@ -25,6 +25,7 @@ enum irq_domain_bus_token {
DOMAIN_BUS_PCI_DEVICE_MSIX,
DOMAIN_BUS_DMAR,
DOMAIN_BUS_AMDVI,
+ DOMAIN_BUS_PCI_DEVICE_IMS,
};
#endif /* _LINUX_IRQDOMAIN_DEFS_H */
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -529,6 +529,8 @@ enum {
MSI_FLAG_MSIX_CONTIGUOUS = (1 << 19),
/* PCI/MSI-X vectors can be dynamically allocated/freed post MSI-X enable */
MSI_FLAG_PCI_MSIX_ALLOC_DYN = (1 << 20),
+ /* Support for PCI/IMS */
+ MSI_FLAG_PCI_IMS = (1 << 21),
};
/**
--- a/include/linux/msi_api.h
+++ b/include/linux/msi_api.h
@@ -15,6 +15,7 @@ struct device;
*/
enum msi_domain_ids {
MSI_DEFAULT_DOMAIN,
+ MSI_SECONDARY_DOMAIN,
MSI_MAX_DEVICE_IRQDOMAINS,
};
> From: Thomas Gleixner <[email protected]>
> Sent: Monday, November 21, 2022 10:38 PM
> /**
> --- a/include/linux/msi_api.h
> +++ b/include/linux/msi_api.h
> @@ -15,6 +15,7 @@ struct device;
> */
> enum msi_domain_ids {
> MSI_DEFAULT_DOMAIN,
> + MSI_SECONDARY_DOMAIN,
> MSI_MAX_DEVICE_IRQDOMAINS,
SECONDARY or be explicit IMS? Are we envisioning non-IMS usages to
occupy this slot in the future?
On Thu, Nov 24 2022 at 03:01, Kevin Tian wrote:
>> From: Thomas Gleixner <[email protected]>
>> @@ -15,6 +15,7 @@ struct device;
>> */
>> enum msi_domain_ids {
>> MSI_DEFAULT_DOMAIN,
>> + MSI_SECONDARY_DOMAIN,
>> MSI_MAX_DEVICE_IRQDOMAINS,
>
> SECONDARY or be explicit IMS? Are we envisioning non-IMS usages to
> occupy this slot in the future?
I'm not really decided on that. Whatever the name or use-case for a
secondary domain is. Not, that this is not restricted to PCI.
Thanks,
tglx
On Thu, Nov 24 2022 at 09:09, Jason Gunthorpe wrote:
> On Thu, Nov 24, 2022 at 10:10:05AM +0100, Thomas Gleixner wrote:
>> On Thu, Nov 24 2022 at 03:01, Kevin Tian wrote:
>> > SECONDARY or be explicit IMS? Are we envisioning non-IMS usages to
>> > occupy this slot in the future?
>>
>> I'm not really decided on that. Whatever the name or use-case for a
>> secondary domain is. Not, that this is not restricted to PCI.
>
> This is hierarchical right? So if a pci_device spawns an
> auxiliary_device, its driver could stick a msi domain on the
> MSI_DEFAULT_DOMAIN of the aux device as a child of the PCI device's
> domain?
A child of the PCI devices parent domain. The per device domains are
endpoint domains. They cannot serve as parent domains themself right
now.
If there is a real reason and use case which requires that, it can be
made work with trivial tweaks.
Thanks,
tglx
On Thu, Nov 24, 2022 at 10:10:05AM +0100, Thomas Gleixner wrote:
> On Thu, Nov 24 2022 at 03:01, Kevin Tian wrote:
> >> From: Thomas Gleixner <[email protected]>
> >> @@ -15,6 +15,7 @@ struct device;
> >> */
> >> enum msi_domain_ids {
> >> MSI_DEFAULT_DOMAIN,
> >> + MSI_SECONDARY_DOMAIN,
> >> MSI_MAX_DEVICE_IRQDOMAINS,
> >
> > SECONDARY or be explicit IMS? Are we envisioning non-IMS usages to
> > occupy this slot in the future?
>
> I'm not really decided on that. Whatever the name or use-case for a
> secondary domain is. Not, that this is not restricted to PCI.
This is hierarchical right? So if a pci_device spawns an
auxiliary_device, its driver could stick a msi domain on the
MSI_DEFAULT_DOMAIN of the aux device as a child of the PCI device's
domain?
I don't know if we need per "ADI" msi domains, but it seems OK to me
to hav have two slots for now and be general about what can go in
those slots
Jason