On Fri, Nov 01 2024 at 23:19, Jarkko Sakkinen wrote:
> On Fri Nov 1, 2024 at 11:13 PM EET, Jarkko Sakkinen wrote:
>> I think we can sort them out independently as long as we find a
>> conclusion how to address locality change.
>
> And to be fair: there was no reaction from anyone. It is mostly x86
On Fri, Nov 01 2024 at 12:28, Jarkko Sakkinen wrote:
> On Fri Sep 13, 2024 at 11:04 PM EEST, Ross Philipson wrote:
>> A quick note on terminology. The larger open source project itself is called
>> TrenchBoot, which is hosted on Github (links below). The kernel feature
>> enabling
>> the use of Dy
On Fri, Nov 01 2024 at 00:37, Jarkko Sakkinen wrote:
> On Thu Oct 31, 2024 at 9:25 PM EET, Thomas Gleixner wrote:
>> So this looks pretty reasonable to me by now and I'm inclined to take it
>> through the tip x86 tree, but that needs reviewed/acked-by's from the
>>
On Fri, Sep 13 2024 at 13:04, Ross Philipson wrote:
> The larger focus of the TrenchBoot project (https://github.com/TrenchBoot) is
> to
> enhance the boot security and integrity in a unified manner. The first area of
> focus has been on the Trusted Computing Group's Dynamic Launch for
> establis
On Thu, Aug 15 2024 at 13:38, Daniel P. Smith wrote:
> On 5/31/24 09:54, Eric W. Biederman wrote:
>> Eric Biggers writes:
>>> That paragraph is also phrased as a hypothetical, "Even if we'd prefer to
>>> use
>>> SHA-256-only". That implies that you do not, in fact, prefer SHA-256 only.
>>> Is
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);
>>
>&
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.
>
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 check for
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 NMI has
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.
>> + */
>> +lockup_detector_rec
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 actual
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 indire
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 be writte
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 pro
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 ad
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 ma
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 up
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 s
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
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
s/IRQ/interrupt/
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 i
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
https://lists.linuxfoundation.org/mailman/listinfo/io
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 structs"
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 (si
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
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
_
ly user of mm_pasid_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
___
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
een 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
k/clone.
>
> 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
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
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 refe
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
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 aa5f09ca
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
cob 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
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
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
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
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
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
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 of
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
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 does not
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 DECLARE_IOASID_SET(iommu_sva_
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
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
> -next. It
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
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
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
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.
>
> Mor
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
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..
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/
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
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 ee907874
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
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 re
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 thou
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 i
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 b
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
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
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
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
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
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
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
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
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
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
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
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:
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
Rev
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
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
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
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
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-by
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
Review
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
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
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
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
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
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
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
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
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
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
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
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 of
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:
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
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
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/
ing 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
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 somet
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
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.
1 - 100 of 588 matches
Mail list logo
