Re: [PATCH v6 22/29] x86/watchdog/hardlockup: Add an HPET-based hardlockup detector

2022-05-14 Thread Thomas Gleixner
On Fri, May 13 2022 at 15:16, Ricardo Neri wrote: > On Mon, May 09, 2022 at 04:03:39PM +0200, Thomas Gleixner wrote: >> > + /* If we are here, IPI shorthands are enabled. */ >> > + apic->send_IPI_allbutself(NMI_VECTOR); >>

Re: [PATCH v6 15/29] x86/hpet: Add helper function hpet_set_comparator_periodic()

2022-05-14 Thread Thomas Gleixner
On Fri, May 13 2022 at 14:19, Ricardo Neri wrote: > On Fri, May 06, 2022 at 11:41:13PM +0200, Thomas Gleixner wrote: >> The argument about not bloating the code >> with an "obvious???" function which is quite small is slightly beyond my >> comprehension level. >

Re: [PATCH v6 05/29] x86/apic/vector: Do not allocate vectors for NMIs

2022-05-14 Thread Thomas Gleixner
On Fri, May 13 2022 at 16:45, Ricardo Neri wrote: > On Fri, May 13, 2022 at 10:50:09PM +0200, Thomas Gleixner wrote: >> > Also, if lapic_nmi_controller.irq_set_affinity() is NULL, then irq_chips >> > INTEL-IR, AMD-IR, those using msi_domain_set_affinity() need to

Re: [PATCH v6 05/29] x86/apic/vector: Do not allocate vectors for NMIs

2022-05-13 Thread Thomas Gleixner
On Fri, May 13 2022 at 11:03, Ricardo Neri wrote: > On Fri, May 06, 2022 at 11:12:20PM +0200, Thomas Gleixner wrote: >> Why would a NMI ever end up in this code? There is no vector management >> required and this find cpu exercise is pointless. > > But even if the N

Re: [PATCH v6 28/29] x86/tsc: Restart NMI watchdog after refining tsc_khz

2022-05-10 Thread Thomas Gleixner
On Tue, May 10 2022 at 21:16, Nicholas Piggin wrote: > Excerpts from Ricardo Neri's message of May 6, 2022 10:00 am: >> +/* >> + * If in use, the HPET hardlockup detector relies on tsc_khz. >> + * Reconfigure it to make use of the refined tsc_khz. >> + */ >> +

Re: [PATCH v6 22/29] x86/watchdog/hardlockup: Add an HPET-based hardlockup detector

2022-05-09 Thread Thomas Gleixner
On Thu, May 05 2022 at 17:00, Ricardo Neri wrote: > + if (is_hpet_hld_interrupt(hdata)) { > + /* > + * Kick the timer first. If the HPET channel is periodic, it > + * helps to reduce the delta between the expected TSC value and > + * its

Re: [PATCH v6 21/29] x86/nmi: Add an NMI_WATCHDOG NMI handler category

2022-05-09 Thread Thomas Gleixner
On Thu, May 05 2022 at 17:00, Ricardo Neri wrote: > Add a NMI_WATCHDOG as a new category of NMI handler. This new category > is to be used with the HPET-based hardlockup detector. This detector > does not have a direct way of checking if the HPET timer is the source of > the NMI. Instead, it

Re: [PATCH v6 15/29] x86/hpet: Add helper function hpet_set_comparator_periodic()

2022-05-06 Thread Thomas Gleixner
On Fri, May 06 2022 at 23:41, Thomas Gleixner wrote: > On Thu, May 05 2022 at 16:59, Ricardo Neri wrote: >> Programming an HPET channel as periodic requires setting the >> HPET_TN_SETVAL bit in the channel configuration. Plus, the comparator >> register must b

Re: [PATCH v6 15/29] x86/hpet: Add helper function hpet_set_comparator_periodic()

2022-05-06 Thread Thomas Gleixner
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote: > Programming an HPET channel as periodic requires setting the > HPET_TN_SETVAL bit in the channel configuration. Plus, the comparator > register must be written twice (once for the comparator value and once for > the periodic value). Since this

Re: [PATCH v6 13/29] iommu/amd: Compose MSI messages for NMI irqs in non-IR format

2022-05-06 Thread Thomas Gleixner
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote: > + * > + * Also, NMIs do not have an associated vector. No need for cleanup. They have a vector and what the heck is this cleanup comment for here? There is nothing cleanup alike anywhere near. Adding confusing comments is worse than

Re: [PATCH v6 12/29] iommu/amd: Enable NMIPass when allocating an NMI irq

2022-05-06 Thread Thomas Gleixner
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote: > > + if (info->flags & X86_IRQ_ALLOC_AS_NMI) { > + /* Only one IRQ per NMI */ > + if (nr_irqs != 1) > + return -EINVAL; See previous reply. ___ iommu

Re: [PATCH v6 10/29] iommu/vt-d: Implement minor tweaks for NMI irqs

2022-05-06 Thread Thomas Gleixner
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote: > The Intel IOMMU interrupt remapping driver already programs correctly the > delivery mode of individual irqs as per their irq_data. Improve handling > of NMIs. Allow only one irq per NMI. Also, it is not necessary to cleanup > irq vectors after

Re: [PATCH v6 05/29] x86/apic/vector: Do not allocate vectors for NMIs

2022-05-06 Thread Thomas Gleixner
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote: > Vectors are meaningless when allocating IRQs with NMI as the delivery > mode. Vectors are not meaningless. NMI has a fixed vector. The point is that for a fixed vector there is no vector management required. Can you spot the difference? > In

Re: [PATCH v6 03/29] x86/apic/msi: Set the delivery mode individually for each IRQ

2022-05-06 Thread Thomas Gleixner
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. > Use the mode specified in the provided IRQ hardware > configuration data. Since most of the IRQs are

Re: [PATCH v6 02/29] x86/apic: Add irq_cfg::delivery_mode

2022-05-06 Thread Thomas Gleixner
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote: > Currently, the delivery mode of all interrupts is set to the mode of the > APIC driver in use. There are no restrictions in hardware to configure the > delivery mode of each interrupt individually. Also, certain IRQs need > to be

Re: [PATCH v6 01/29] irq/matrix: Expose functions to allocate the best CPU for new vectors

2022-05-06 Thread Thomas Gleixner
Ricardo, On Thu, May 05 2022 at 16:59, Ricardo Neri wrote: > Certain types of interrupts, such as NMI, do not have an associated vector. > They, however, target specific CPUs. Thus, when assigning the destination > CPU, it is beneficial to select the one with the lowest number of > vectors. Why

Re: [PATCH v2] iommu/sva: Fix PASID use-after-free issue

2022-05-06 Thread Thomas Gleixner
On Fri, May 06 2022 at 09:49, Zhangfei Gao wrote: > Will this be taken for 5.18? It's queued in tip core/urgent and will go to Linus this week. ___ iommu mailing list iommu@lists.linux-foundation.org

Re: [PATCH] x86/msi: Fix msi message data shadow struct

2022-04-06 Thread Thomas Gleixner
Reto, On Wed, Apr 06 2022 at 10:36, Reto Buerki wrote: > The x86 MSI message data is 32 bits in total and is either in > compatibility or remappable format, see Intel Virtualization Technology > for Directed I/O, section 5.1.2. > > Fixes: 6285aa50736 ("x86/msi: Provide msi message shadow

Re: [PATCH v3 12/35] x86/msi: Provide msi message shadow structs

2022-04-06 Thread Thomas Gleixner
On Wed, Apr 06 2022 at 10:36, Reto Buerki wrote: > While working on some out-of-tree patches, we noticed that assignment to > dmar_subhandle of struct x86_msi_data lead to a QEMU warning about > reserved bits in MSI data being set: > > qemu-system-x86_64: vtd_interrupt_remap_msi: invalid IR MSI

Re: [PATCH v4 11/11] docs: x86: Change documentation for SVA (Shared Virtual Addressing)

2022-02-14 Thread Thomas Gleixner
On Mon, Feb 07 2022 at 15:02, Fenghua Yu wrote: > Since allocating, freeing and fixing up PASID are changed, the > documentation is updated to reflect the changes. > > Originally-by: Ashok Raj > Signed-off-by: Fenghua Yu > Reviewed-by: Tony Luck Acked-b

Re: [PATCH v4 05/11] iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit

2022-02-14 Thread Thomas Gleixner
lifetime bound to the life time of the process. > > Get rid of the refcounting mechanisms and replace/rename the interfaces > to reflect this new approach. > > Suggested-by: Dave Hansen > Signed-off-by: Fenghua Yu > Reviewed-by: Tony Luck Reviewed-by: Thomas Gleixner _

Re: [PATCH v4 04/11] kernel/fork: Initialize mm's PASID

2022-02-14 Thread Thomas Gleixner
id_init() is in fork.c, define it > in as the first of three mm/pasid life cycle > functions (init/set/drop) to keep these all together. > > Suggested-by: Dave Hansen > Signed-off-by: Fenghua Yu > Reviewed-by: Tony Luck Reviewed-by: Thomas Gleixner

Re: [PATCH v3 09/11] x86/cpufeatures: Re-enable ENQCMD

2022-02-04 Thread Thomas Gleixner
d() can be used to check the feature. > > Signed-off-by: Fenghua Yu > Reviewed-by: Tony Luck Reviewed-by: Thomas Gleixner ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 08/11] x86/traps: Demand-populate PASID MSR via #GP

2022-02-04 Thread Thomas Gleixner
dy been allocated a PASID. If so, try to fix the #GP fault by > loading the IA32_PASID MSR. > > Signed-off-by: Fenghua Yu > Reviewed-by: Tony Luck Reviewed-by: Thomas Gleixner ___ iommu mailing list iommu@lists.linux-foundation.org https://lists

Re: [PATCH v3 07/11] sched: Define and initialize a flag to identify valid PASID in the task

2022-02-04 Thread Thomas Gleixner
ne. > > Signed-off-by: Peter Zijlstra > Co-developed-by: Fenghua Yu > Signed-off-by: Fenghua Yu > Reviewed-by: Tony Luck Reviewed-by: Thomas Gleixner ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 06/11] x86/fpu: Clear PASID when copying fpstate

2022-02-04 Thread Thomas Gleixner
On Fri, Jan 28 2022 at 12:29, Fenghua Yu wrote: > Signed-off-by: Fenghua Yu > Reviewed-by: Tony Luck Reviewed-by: Thomas Gleixner ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 05/11] iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit

2022-02-04 Thread Thomas Gleixner
On Fri, Jan 28 2022 at 12:28, Fenghua Yu wrote: > To avoid complexity of updating each thread's PASID status (e.g. sending > IPI to update IA32_PASID MSR) on allocating and freeing PASID, once > allocated and assigned to an mm, the PASID stays with the mm for the > rest of the mm's lifetime. A

Re: [PATCH v3 03/11] iommu/ioasid: Introduce a helper to check for valid PASIDs

2022-02-04 Thread Thomas Gleixner
On Fri, Jan 28 2022 at 12:28, Fenghua Yu wrote: > pasid_valid() is defined to check if a given PASID is valid. > > Suggested-by: Ashok Raj > Suggested-by: Jacob Pan > Signed-off-by: Fenghua Yu > Reviewed-by: Tony Luck Reviewed-b

Re: [PATCH v3 04/11] kernel/fork: Initialize mm's PASID

2022-02-04 Thread Thomas Gleixner
On Fri, Jan 28 2022 at 12:28, Fenghua Yu wrote: > A new mm doesn't have a PASID yet when it's created. Initialize > the mm's PASID on fork() or for init_mm to INVALID_IOASID (-1). I must be missing something here. > diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h > index

Re: [PATCH v3 03/11] iommu/ioasid: Introduce a helper to check for valid PASIDs

2022-02-04 Thread Thomas Gleixner
On Fri, Jan 28 2022 at 12:28, Fenghua Yu wrote: > pasid_valid() is defined to check if a given PASID is valid. > > Suggested-by: Ashok Raj > Suggested-by: Jacob Pan > Signed-off-by: Fenghua Yu > Reviewed-by: Tony Luck Reviewed-b

Re: [PATCH v3 02/11] mm: Change CONFIG option for mm->pasid field

2022-02-04 Thread Thomas Gleixner
Jacob Pan > Signed-off-by: Fenghua Yu > Reviewed-by: Tony Luck Reviewed-by: Thomas Gleixner ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 01/11] iommu/sva: Rename CONFIG_IOMMU_SVA_LIB to CONFIG_IOMMU_SVA

2022-02-04 Thread Thomas Gleixner
on > options for all code relating to SVA. > > Signed-off-by: Fenghua Yu > Reviewed-by: Tony Luck Reviewed-by: Thomas Gleixner ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [patch V3 28/35] PCI/MSI: Simplify pci_irq_get_affinity()

2022-01-31 Thread Thomas Gleixner
Thanks, tglx --- Subject: PCI/MSI: Remove bogus warning in pci_irq_get_affinity() From: Thomas Gleixner Date: Mon, 31 Jan 2022 22:02:46 +0100 The recent overhaul of pci_irq_get_affinity() introduced a regression when pci_irq_get_affinity() is called for an MSI-X interrupt which was not all

Re: [patch V3 28/35] PCI/MSI: Simplify pci_irq_get_affinity()

2022-01-31 Thread Thomas Gleixner
On Sun, Jan 30 2022 at 09:12, Guenter Roeck wrote: > On Fri, Dec 10, 2021 at 11:19:26PM +0100, Thomas Gleixner wrote: > This patch results in the following runtime warning when booting x86 > (32 bit) nosmp images from NVME in qemu. > > [ 14.825482] nvme nvme0: 1/0/0 default/r

Re: [PATCH v2 05/11] iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit

2022-01-28 Thread Thomas Gleixner
On Thu, Jan 27 2022 at 18:42, Fenghua Yu wrote: > On Wed, Jan 26, 2022 at 10:38:04PM +0100, Thomas Gleixner wrote: >> Against Linus tree please so that the bugfix applies. >> >> > I will fold the following patch into patch #5. The patch #11 (the doc >> > pat

Re: [PATCH v2 05/11] iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit

2022-01-26 Thread Thomas Gleixner
On Wed, Jan 26 2022 at 09:36, Fenghua Yu wrote: > On Wed, Jan 26, 2022 at 03:23:42PM +0100, Thomas Gleixner wrote: >> On Tue, Jan 25 2022 at 07:18, Fenghua Yu wrote: >> While looking at ioasid_put() usage I tripped over the following UAF >> issue: >> >> --- a/dri

Re: [PATCH v2 05/11] iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit

2022-01-26 Thread Thomas Gleixner
On Tue, Jan 25 2022 at 07:18, Fenghua Yu wrote: > On Mon, Jan 24, 2022 at 09:55:56PM +0100, Thomas Gleixner wrote: > /** > * ioasid_put - Release a reference to an ioasid > * @ioasid: the ID to remove which in turn makes ioasid_put() a misnomer and the whole refcounting o

Re: [PATCH v2 05/11] iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit

2022-01-24 Thread Thomas Gleixner
On Mon, Jan 24 2022 at 12:52, Fenghua Yu wrote: > On Mon, Jan 24, 2022 at 09:36:00PM +0100, Thomas Gleixner wrote: >> On Mon, Jan 24 2022 at 21:21, Thomas Gleixner wrote: > Ah. This patch should remove ioasid_get(). So I will change this patch > as follows: > > 1. Remove ioas

Re: [PATCH v2 05/11] iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit

2022-01-24 Thread Thomas Gleixner
On Mon, Jan 24 2022 at 21:21, Thomas Gleixner wrote: > > Hrm. This is odd. > >> +/* Associate a PASID with an mm_struct: */ >> +static inline void mm_pasid_get(struct mm_struct *mm, u32 pasid) >> +{ >> +mm->pasid = pasid; >> +} > > This do

Re: [PATCH v2 05/11] iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit

2022-01-24 Thread Thomas Gleixner
On Fri, Dec 17 2021 at 22:01, Fenghua Yu wrote: > diff --git a/drivers/iommu/iommu-sva-lib.c b/drivers/iommu/iommu-sva-lib.c > index bd41405d34e9..ee2294e02716 100644 > --- a/drivers/iommu/iommu-sva-lib.c > +++ b/drivers/iommu/iommu-sva-lib.c > @@ -18,8 +18,7 @@ static

Re: [patch V3 28/35] PCI/MSI: Simplify pci_irq_get_affinity()

2021-12-20 Thread Thomas Gleixner
On Sat, Dec 18 2021 at 21:25, Cédric Le Goater wrote: > On 12/18/21 11:25, Thomas Gleixner wrote: >> On Fri, Dec 17 2021 at 15:30, Nathan Chancellor wrote: >>> On Fri, Dec 10, 2021 at 11:19:26PM +0100, Thomas Gleixner wrote: >>> I just bisected a boot failure on my AMD

Re: [patch V3 28/35] PCI/MSI: Simplify pci_irq_get_affinity()

2021-12-18 Thread Thomas Gleixner
On Fri, Dec 17 2021 at 15:30, Nathan Chancellor wrote: > On Fri, Dec 10, 2021 at 11:19:26PM +0100, Thomas Gleixner wrote: > I just bisected a boot failure on my AMD test desktop to this patch as > commit f48235900182 ("PCI/MSI: Simplify pci_irq_get_affinity()") in >

Re: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2

2021-12-16 Thread Thomas Gleixner
Nishanth, On Wed, Dec 15 2021 at 19:45, Nishanth Menon wrote: > On 17:35-20211215, Thomas Gleixner wrote: > Thanks once again for your help. Hope we can roll in the fixes for > part3. Sure, it's only the one-liner for ti sci. Got it folded already. Thanks for your help and testing!

[patch V4 09-02/35] PCI/MSI: Allocate MSI device data on first use

2021-12-15 Thread Thomas Gleixner
Allocate MSI device data on first use, i.e. when a PCI driver invokes one of the PCI/MSI enablement functions. Add a wrapper function to ensure that the ordering vs. pcim_msi_release() is correct. Signed-off-by: Thomas Gleixner --- V4: Adopted to ensure devres ordering --- drivers/pci/msi

[patch V4 09-01/35] PCI/MSI: Decouple MSI[-X] disable from pcim_release()

2021-12-15 Thread Thomas Gleixner
allocation to be ordered correctly in a subsequent step. Reported-by: Nishanth Menon Signed-off-by: Thomas Gleixner --- V4: New patch --- drivers/pci/msi/msi.c | 33 + drivers/pci/pci.c |5 - include/linux/pci.h |3 ++- 3 files changed, 35

Re: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2

2021-12-15 Thread Thomas Gleixner
On Wed, Dec 15 2021 at 17:18, Thomas Gleixner wrote: > On Tue, Dec 14 2021 at 22:19, Thomas Gleixner wrote: >> On Tue, Dec 14 2021 at 14:56, Nishanth Menon wrote: >> >> thanks for trying. I'll have a look again with brain awake tomorrow >> morning. > > Morning

Re: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2

2021-12-15 Thread Thomas Gleixner
On Tue, Dec 14 2021 at 22:19, Thomas Gleixner wrote: > On Tue, Dec 14 2021 at 14:56, Nishanth Menon wrote: > > thanks for trying. I'll have a look again with brain awake tomorrow > morning. Morning was busy with other things, but I found what my sleepy brain managed to do wrong yeste

Re: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2

2021-12-14 Thread Thomas Gleixner
Nishanth, On Tue, Dec 14 2021 at 14:56, Nishanth Menon wrote: > On 21:15-20211214, Thomas Gleixner wrote: >> I think I managed to distangle this. Can you please give: >> >>git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git msi-v4-part-2 > > > Umm

Re: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2

2021-12-14 Thread Thomas Gleixner
Nishanth, On Tue, Dec 14 2021 at 18:03, Thomas Gleixner wrote: > msi_device_data_release() > ... > pcim_release() >pci_disable_msi[x]() > > Groan I think I managed to distangle this. Can you please give: git://git.kernel.org/pub/scm/linux/kernel/git/

Re: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2

2021-12-14 Thread Thomas Gleixner
On Tue, Dec 14 2021 at 17:36, Thomas Gleixner wrote: > On Tue, Dec 14 2021 at 10:22, Nishanth Menon wrote: >> On 10:41-20211214, Thomas Gleixner wrote: > [ 13.478122] Call trace: > [ 13.509042] msi_device_destroy_sysfs+0x18/0x88 > [ 13.509058] msi_domain_free_irqs+0x34/0x

Re: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2

2021-12-14 Thread Thomas Gleixner
On Tue, Dec 14 2021 at 10:22, Nishanth Menon wrote: > On 10:41-20211214, Thomas Gleixner wrote: > Agreed that the warning is fine, the null pointer exception that follows > [1] [2] it however does'nt look right and it can be trivially fixed with the > following fixup for ee90787487bc

Re: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2

2021-12-14 Thread Thomas Gleixner
On Mon, Dec 13 2021 at 12:29, Nishanth Menon wrote: > On 23:18-20211210, Thomas Gleixner wrote: > Also while testing on TI K3 platforms, I noticed: > > msi_device_data_release/msi_device_destroy_sysfs in am64xx-evm / j7200 The warning complains about a device being released with MSI

RE: [patch 21/32] NTB/msi: Convert to msi_on_each_desc()

2021-12-12 Thread Thomas Gleixner
Kevin, On Sun, Dec 12 2021 at 01:56, Kevin Tian wrote: >> From: Thomas Gleixner >> All I can find is drivers/iommu/virtio-iommu.c but I can't find anything >> vIR related there. > > Well, virtio-iommu is a para-virtualized vIOMMU implementations. > > In reality

RE: [patch 21/32] NTB/msi: Convert to msi_on_each_desc()

2021-12-12 Thread Thomas Gleixner
Kevin, On Sun, Dec 12 2021 at 02:14, Kevin Tian wrote: >> From: Thomas Gleixner > I just continue the thought practice along that direction to see what > the host flow will be like (step by step). Looking at the current > implementation is just one necessary step in my t

RE: [patch 21/32] NTB/msi: Convert to msi_on_each_desc()

2021-12-11 Thread Thomas Gleixner
Kevin, On Sat, Dec 11 2021 at 07:52, Kevin Tian wrote: >> From: Jason Gunthorpe >> > Then Qemu needs to find out the GSI number for the vIRTE handle. >> > Again Qemu doesn't have such information since it doesn't know >> > which MSI[-X] entry points to this handle due to no trap. >> >> No this

RE: [patch 21/32] NTB/msi: Convert to msi_on_each_desc()

2021-12-11 Thread Thomas Gleixner
Kevin, On Sat, Dec 11 2021 at 07:44, Kevin Tian wrote: >> From: Thomas Gleixner >> On Fri, Dec 10 2021 at 08:39, Jason Gunthorpe wrote: >> > It is clever, we don't have an vIOMMU that supplies vIR today, so by >> > definition all guests are excluded and only bare m

[patch V3 34/35] soc: ti: ti_sci_inta_msi: Get rid of ti_sci_inta_msi_get_virq()

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Just use the core function msi_get_virq(). Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe Cc: Peter Ujfalusi Cc: Vinod Koul Cc: dmaeng...@vger.kernel.org --- drivers/dma/ti/k3-udma-private.c |6 ++ drivers

[patch V3 35/35] dmaengine: qcom_hidma: Cleanup MSI handling

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner There is no reason to walk the MSI descriptors to retrieve the interrupt number for a device. Use msi_get_virq() instead. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe Acked-by: Sinan Kaya Cc: dmaeng...@vger.kernel.org

[patch V3 33/35] bus: fsl-mc: fsl-mc-allocator: Rework MSI handling

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Storing a pointer to the MSI descriptor just to track the Linux interrupt number is daft. Just store the interrupt number and be done with it. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe Cc: Stuart Yoder Cc: Laurentiu

[patch V3 32/35] mailbox: bcm-flexrm-mailbox: Rework MSI interrupt handling

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner No point in retrieving the MSI descriptors. Just query the Linux interrupt number. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe Cc: Jassi Brar --- drivers/mailbox/bcm-flexrm-mailbox.c |7 ++- 1 file changed, 2

[patch V3 31/35] iommu/arm-smmu-v3: Use msi_get_virq()

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Let the core code fiddle with the MSI descriptor retrieval. Signed-off-by: Thomas Gleixner Tested-by: Robin Murphy Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe Cc: Will Deacon Cc: Joerg Roedel Cc: linux-arm-ker...@lists.infradead.org Cc: iommu

[patch V3 30/35] perf/smmuv3: Use msi_get_virq()

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Let the core code fiddle with the MSI descriptor retrieval. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe Cc: Mark Rutland Cc: Will Deacon Cc: linux-arm-ker...@lists.infradead.org --- drivers/perf/arm_smmuv3_pmu.c |5

[patch V3 29/35] dmaengine: mv_xor_v2: Get rid of msi_desc abuse

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Storing a pointer to the MSI descriptor just to keep track of the Linux interrupt number is daft. Use msi_get_virq() instead. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe Cc: Vinod Koul Cc: dmaeng...@vger.kernel.org

[patch V3 28/35] PCI/MSI: Simplify pci_irq_get_affinity()

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Replace open coded MSI descriptor chasing and use the proper accessor functions instead. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe --- drivers/pci/msi/msi.c | 26 ++ 1 file changed, 10

[patch V3 27/35] PCI/MSI: Use __msi_get_virq() in pci_get_vector()

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Use msi_get_vector() and handle the return value to be compatible. No functional change intended. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman --- V2: Handle the INTx case directly instead of trying to be overly smart - Marc --- drivers/pci/msi/msi.c

[patch V3 26/35] genirq/msi: Provide interface to retrieve Linux interrupt number

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner This allows drivers to retrieve the Linux interrupt number instead of fiddling with MSI descriptors. msi_get_virq() returns the Linux interrupt number or 0 in case that there is no entry for the given MSI index. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah

[patch V3 25/35] powerpc/pseries/msi: Let core code check for contiguous entries

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Set the domain info flag and remove the check. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: "Cédric Le Goater" Cc: linuxppc-...@lists.ozlabs.org --- V2: Remove it completely - Cedric

[patch V3 24/35] PCI/MSI: Provide MSI_FLAG_MSIX_CONTIGUOUS

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Provide a domain info flag which makes the core code check for a contiguous MSI-X index on allocation. That's simpler than checking it at some other domain callback in architecture code. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason

[patch V3 23/35] PCI/MSI: Use msi_desc::msi_index

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner The usage of msi_desc::pci::entry_nr is confusing at best. It's the index into the MSI[X] descriptor table. Use msi_desc::msi_index which is shared between all MSI incarnations instead of having a PCI specific storage for no value. Signed-off-by: Thomas Gleixner Reviewed

[patch V3 21/35] bus: fsl-mc-msi: Use msi_desc::msi_index

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Use the common msi_index member and get rid of the pointless wrapper struct. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe Cc: Stuart Yoder Cc: Laurentiu Tudor --- drivers/bus/fsl-mc/fsl-mc-allocator.c |2 +- drivers

[patch V3 22/35] soc: ti: ti_sci_inta_msi: Use msi_desc::msi_index

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Use the common msi_index member and get rid of the pointless wrapper struct. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe Cc: Nishanth Menon Cc: Tero Kristo Cc: Santosh Shilimkar Cc: Thomas Gleixner Cc: linux-arm-ker

[patch V3 18/35] platform-msi: Store platform private data pointer in msi_device_data

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Storing the platform private data in a MSI descriptor is sloppy at best. The data belongs to the device and not to the descriptor. Add a pointer to struct msi_device_data and store the pointer there. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed

[patch V3 20/35] platform-msi: Use msi_desc::msi_index

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Use the common msi_index member and get rid of the pointless wrapper struct. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe --- drivers/base/platform-msi.c | 10 +- drivers/dma/qcom/hidma.c

[patch V3 19/35] genirq/msi: Consolidate MSI descriptor data

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner All non PCI/MSI usage variants have data structures in struct msi_desc with only one member: xxx_index. PCI/MSI has a entry_nr member. Add a common msi_index member to struct msi_desc so all implementations can share it which allows further consolidation. Signed-off

[patch V3 17/35] platform-msi: Rename functions and clarify comments

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner It's hard to distinguish what platform_msi_domain_alloc() and platform_msi_domain_alloc_irqs() are about. Make the distinction more explicit and add comments which explain the use cases properly. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed

[patch V3 16/35] genirq/msi: Remove the original sysfs interfaces

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner No more users. Refactor the core code accordingly and move the global interface under CONFIG_PCI_MSI_ARCH_FALLBACKS. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe --- include/linux/msi.h | 29

[patch V3 15/35] platform-msi: Let the core code handle sysfs groups

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Set the domain info flag and remove the local sysfs code. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe --- drivers/base/platform-msi.c | 11 +-- 1 file changed, 1 insertion(+), 10 deletions(-) --- a/drivers/base

[patch V3 14/35] PCI/MSI: Let the irq code handle sysfs groups

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Set the domain info flag which makes the core code handle sysfs groups and put an explicit invocation into the legacy code. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe Acked-by: Bjorn Helgaas --- drivers/pci/msi

[patch V3 12/35] soc: ti: ti_sci_inta_msi: Allocate MSI device data on first use

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Allocate the MSI device data on first invocation of the allocation function. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe Cc: Nishanth Menon Cc: Tero Kristo Cc: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org

[patch V3 13/35] genirq/msi: Provide msi_device_populate/destroy_sysfs()

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Add new allocation functions which can be activated by domain info flags. They store the groups pointer in struct msi_device_data. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe --- include/linux/msi.h |4 kernel

[patch V3 11/35] bus: fsl-mc-msi: Allocate MSI device data on first use

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Allocate the MSI device data on first invocation of the allocation function. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe Cc: Stuart Yoder Cc: Laurentiu Tudor --- drivers/bus/fsl-mc/fsl-mc-msi.c | 14 -- 1

[patch V3 09/35] PCI/MSI: Allocate MSI device data on first use

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Allocate MSI device data on first use, i.e. when a PCI driver invokes one of the PCI/MSI enablement functions. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe Acked-by: Bjorn Helgaas --- drivers/pci/msi/msi.c | 20

[patch V3 10/35] platform-msi: Allocate MSI device data on first use

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Allocate the MSI device data on first invocation of the allocation function for platform MSI private data. Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe --- drivers/base/platform-msi.c |8 +++- 1 file changed, 7

[patch V3 08/35] device: Add device:: Msi_data pointer and struct msi_device_data

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner Create struct msi_device_data and add a pointer of that type to struct dev_msi_info, which is part of struct device. Provide an allocator function which can be invoked from the MSI interrupt allocation code pathes. Add a properties field to the data structure as a first

[patch V3 07/35] device: Move MSI related data into a struct

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner The only unconditional part of MSI data in struct device is the irqdomain pointer. Everything else can be allocated on demand. Create a data structure and move the irqdomain pointer into it. The other MSI specific parts are going to be removed from struct device in later

[patch V3 06/35] powerpc/pseries/msi: Use PCI device properties

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner instead of fiddling with MSI descriptors. Signed-off-by: Thomas Gleixner Cc: Michael Ellerman Cc: linuxppc-...@lists.ozlabs.org --- V3: Use pci_dev->msix_enabled - Jason --- arch/powerpc/platforms/pseries/msi.c |3 +-- 1 file changed, 1 insertion(+), 2 deleti

[patch V3 05/35] powerpc/cell/axon_msi: Use PCI device property

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner instead of fiddling with MSI descriptors. Signed-off-by: Thomas Gleixner Cc: Arnd Bergmann Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: linuxppc-...@lists.ozlabs.org --- V3: Use pci_dev property - Jason V2: Invoke the function with the correct number

[patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2

2021-12-10 Thread Thomas Gleixner
This is the second part of [PCI]MSI refactoring which aims to provide the ability of expanding MSI-X vectors after enabling MSI-X. This is based on the first part of this work which can be found here: https://lore.kernel.org/r/20211206210147.872865...@linutronix.de and has been applied to:

[patch V3 03/35] x86/apic/msi: Use PCI device MSI property

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner instead of fiddling with MSI descriptors. Signed-off-by: Thomas Gleixner --- V3: Use pci_dev->msix_enabled - Jason --- arch/x86/kernel/apic/msi.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) --- a/arch/x86/kernel/apic/msi.c +++ b/arch/x86/kernel/a

[patch V3 04/35] genirq/msi: Use PCI device property

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner to determine whether this is MSI or MSIX instead of consulting MSI descriptors. Signed-off-by: Thomas Gleixner --- V2: Use PCI device property - Jason --- kernel/irq/msi.c | 17 ++--- 1 file changed, 2 insertions(+), 15 deletions(-) --- a/kernel/irq/msi.c

[patch V3 02/35] x86/pci/XEN: Use PCI device property

2021-12-10 Thread Thomas Gleixner
From: Thomas Gleixner instead of fiddling with MSI descriptors. Signed-off-by: Thomas Gleixner Cc: Juergen Gross Cc: xen-de...@lists.xenproject.org --- V3: Use pci_dev->msix_enabled. --- arch/x86/pci/xen.c |9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) --- a/arch/x86/

[patch V3 01/35] PCI/MSI: Set pci_dev::msi[x]_enabled early

2021-12-10 Thread Thomas Gleixner
of the setup sequence and cleared in case of a failure. Implement that so the MSI descriptor evaluations can be converted to simple property queries. Signed-off-by: Thomas Gleixner --- V3: New patch --- drivers/pci/msi/msi.c | 23 +-- 1 file changed, 17 insertions(+), 6 deletions

Re: [patch 21/32] NTB/msi: Convert to msi_on_each_desc()

2021-12-10 Thread Thomas Gleixner
Jason, On Fri, Dec 10 2021 at 08:39, Jason Gunthorpe wrote: > On Fri, Dec 10, 2021 at 07:29:01AM +, Tian, Kevin wrote: >> > 5) It's not possible for the kernel to reliably detect whether it is >> > running on bare metal or not. Yes we talked about heuristics, but >> > that's

RE: [patch 21/32] NTB/msi: Convert to msi_on_each_desc()

2021-12-10 Thread Thomas Gleixner
Kevin, On Fri, Dec 10 2021 at 07:29, Kevin Tian wrote: >> From: Thomas Gleixner >> 4) For the guest side we agreed that we need an hypercall because the >> host can't trap the write to the MSI[-X] entry anymore. > > To be accurate I'd like to not call it "can'

Re: [patch 21/32] NTB/msi: Convert to msi_on_each_desc()

2021-12-09 Thread Thomas Gleixner
On Thu, Dec 09 2021 at 23:09, Thomas Gleixner wrote: > On Thu, Dec 09 2021 at 16:58, Jason Gunthorpe wrote: >> Okay, I think I get it. Would be nice to have someone from intel >> familiar with the vIOMMU protocols and qemu code remark what the >> hypervisor side can look like.

Re: [patch 21/32] NTB/msi: Convert to msi_on_each_desc()

2021-12-09 Thread Thomas Gleixner
On Thu, Dec 09 2021 at 16:58, Jason Gunthorpe wrote: > On Thu, Dec 09, 2021 at 09:32:42PM +0100, Thomas Gleixner wrote: >> That was my thought to avoid having different mechanisms. >> >> The address/data pair is computed in two places: >> >> 1) Activation

Re: [patch V2 19/36] PCI/MSI: Store properties in device::msi::data

2021-12-09 Thread Thomas Gleixner
On Thu, Dec 09 2021 at 18:53, Thomas Gleixner wrote: > On Wed, Dec 08 2021 at 11:58, Jason Gunthorpe wrote: >> On Mon, Dec 06, 2021 at 11:39:26PM +0100, Thomas Gleixner wrote: >>> Store the properties which are interesting for various places so the MSI >>> descrip

Re: [patch 21/32] NTB/msi: Convert to msi_on_each_desc()

2021-12-09 Thread Thomas Gleixner
On Thu, Dec 09 2021 at 12:21, Jason Gunthorpe wrote: > On Thu, Dec 09, 2021 at 09:37:06AM +0100, Thomas Gleixner wrote: > If we keep the MSI emulation in the hypervisor then MSI != IMS. The > MSI code needs to write a addr/data pair compatible with the emulation > and the IMS code ne

Re: [patch V2 19/36] PCI/MSI: Store properties in device::msi::data

2021-12-09 Thread Thomas Gleixner
On Wed, Dec 08 2021 at 11:58, Jason Gunthorpe wrote: > On Mon, Dec 06, 2021 at 11:39:26PM +0100, Thomas Gleixner wrote: >> Store the properties which are interesting for various places so the MSI >> descriptor fiddling can be removed. >> >> Signed-off-by: Thomas

RE: [patch 21/32] NTB/msi: Convert to msi_on_each_desc()

2021-12-09 Thread Thomas Gleixner
On Thu, Dec 09 2021 at 12:17, Kevin Tian wrote: >> From: Thomas Gleixner >> I think you are looking at that from the internal implementation details >> of IDXD. But you can just model it in an IDXD implementation agnostic >> way: >> >> ENQCMD(PASID,

  1   2   3   4   5   6   >