On Fri, May 06, 2022 at 10:05:34PM +0200, Thomas Gleixner wrote: > On Thu, May 05 2022 at 16:59, Ricardo Neri wrote: > > There are no restrictions in hardware to set MSI messages with its > > own delivery mode. > > "messages with its own" ? Plural/singular confusion.
Yes, this is not correct. It should have read "messages with their own..." > > > Use the mode specified in the provided IRQ hardware > > configuration data. Since most of the IRQs are configured to use the > > delivery mode of the APIC driver in use (set in all of them to > > APIC_DELIVERY_MODE_FIXED), the only functional changes are where > > IRQs are configured to use a specific delivery mode. > > This does not parse. There are no functional changes due to this patch > and there is no point talking about functional changes in subsequent > patches here. I will remove this. > > > Changing the utility function __irq_msi_compose_msg() takes care of > > implementing the change in the in the local APIC, PCI-MSI, and DMAR-MSI > > in the in the Sorry! This is not correct. > > > irq_chips. > > > > The IO-APIC irq_chip configures the entries in the interrupt redirection > > table using the delivery mode specified in the corresponding MSI message. > > Since the MSI message is composed by a higher irq_chip in the hierarchy, > > it does not need to be updated. > > The point is that updating __irq_msi_compose_msg() covers _all_ MSI > consumers including IO-APIC. > > I had to read that changelog 3 times to make sense of it. Something like > this perhaps: > > "x86/apic/msi: Use the delivery mode from irq_cfg for message composition > > irq_cfg provides a delivery mode for each interrupt. Use it instead > of the hardcoded APIC_DELIVERY_MODE_FIXED. This allows to compose > messages for NMI delivery mode which is required to implement a HPET > based NMI watchdog. > > No functional change as the default delivery mode is set to > APIC_DELIVERY_MODE_FIXED." Thank you for your help on the changelog! I will take your suggestion. BR, Ricardo > > Thanks, > > tglx