> -----Original Message-----
> From: Thomas Gleixner <[email protected]>
> Sent: Saturday, November 7, 2020 8:32 AM
> To: Tian, Kevin <[email protected]>; Jason Gunthorpe <[email protected]>
> Cc: Jiang, Dave <[email protected]>; Bjorn Helgaas <[email protected]>;
> [email protected]; Dey, Megha <[email protected]>; [email protected];
> [email protected]; [email protected]; Pan, Jacob jun
> <[email protected]>; Raj, Ashok <[email protected]>; Liu, Yi L
> <[email protected]>; Lu, Baolu <[email protected]>; Kumar, Sanjay K
> <[email protected]>; Luck, Tony <[email protected]>;
> [email protected]; Williams, Dan J <[email protected]>;
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; Ortiz, Samuel
> <[email protected]>; Hossain, Mona <[email protected]>;
> [email protected]; [email protected]; linux-
> [email protected]; [email protected]
> Subject: RE: [PATCH v4 06/17] PCI: add SIOV and IMS capability detection
>
> On Fri, Nov 06 2020 at 09:48, Kevin Tian wrote:
> >> From: Jason Gunthorpe <[email protected]>
> >> On Wed, Nov 04, 2020 at 01:34:08PM +0000, Tian, Kevin wrote:
> >> The interrupt controller is responsible to create an addr/data pair
> >> for an interrupt message. It sets the message format and ensures it
> >> routes to the proper CPU interrupt handler. Everything about the
> >> addr/data pair is owned by the platform interrupt controller.
> >>
> >> Devices do not create interrupts. They only trigger the addr/data pair
> >> the platform gives them.
> >
> > I guess that we may just view it from different angles. On x86 platform,
> > a MSI/IMS capable device directly composes interrupt messages, with
> > addr/data pair filled by OS. If there is no IOMMU remapping enabled in
> > the middle, the message just hits the CPU. Your description possibly
> > is from software side, e.g. describing the hierarchical IRQ domain
> > concept?
>
> No. The device composes nothing. If the interrupt is raised in the
> device then the MSI block sends the message which was composed by the OS
> and stored in the device's message store. For PCI/MSI that's the MSI or
> MSIX table and for IMS that's either on device memory (as IDXD uses) or
> some completely different location which Jason described.
Sorry being inaccurate here. I actually meant the same thing as
you described since I did mention addr/data pair filled by OS.
Unfortunately I mistakenly thought that 'compose' has similar
meaning to 'send' in English but clearly it's not and instead it's
just about the message content. and for sure I also agree with your
other clarifications regarding to architecture independent manner.
Thanks
Kevin
>
> This has absolutely nothing to do with the X86 platform. MSI is a
> architecture independent mechanism: Send whatever the OS put into the
> storage to raise an interrupt in the CPU. The device does neither know
> whether that message is going to be intercepted by an interrupt
> remapping unit or not.
>
> Stop claiming that any of this has anything to do with x86. It has
> absolutely nothing to do with x86 and looking at MSI from an x86
> perspective instead of looking at it from the architecture agnostic
> technical reality of MSI is the reason why we have this discussion at
> all.
>
> We had a similar discussion vs. the way how IMS interrupts have to be
> dealt with in terms of irq domains. Can you finally stop looking at
> everything as a big x86/intel/platform lump and understand that things
> are very well structured and seperated both at the hardware and at the
> software level?
>
> > Do you mind providing the link? There were lots of discussions between
> > you and Thomas. I failed to locate the exact mail when searching above
> > keywords.
>
> In this thread: [email protected] and you were on
> Cc
>
> Thanks,
>
> tglx
>
