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
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
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
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
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
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
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
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
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
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
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
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
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
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 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 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
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
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 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
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/
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..
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
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
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
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
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
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
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 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 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 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 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 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 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 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
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
> 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
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 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
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: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
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
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
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
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
___
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
_
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
more work than I'm willing to do right now.
Yeah, this thing is on the todo list ...
> Signed-off-by: Christoph Hellwig
Other than the above nits:
Reviewed-by: Thomas Gleixner
> ---
> Documentation/x86/x86_64/boot-options.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 de
ristoph Hellwig
Reviewed-by: Thomas Gleixner
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
r now, as it is used in the wild
> to override the too generic VIA quirk.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Thomas Gleixner
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
s rid of the
> arch_dma_supported hook entirely.
Shouldn't this go before the other two?
> Signed-off-by: Christoph Hellwig
Reviewed-by: Thomas Gleixner
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Mon, 28 May 2018, Christoph Hellwig wrote:
> On Mon, May 28, 2018 at 08:10:40AM +0200, Thomas Gleixner wrote:
> > n Fri, 25 May 2018, Christoph Hellwig wrote:
> >
> > x86/pci-dma: ...
> >
> > Please
> >
> > > Instead of globally disabling >
On Mon, 28 May 2018, Christoph Hellwig wrote:
> On Mon, May 28, 2018 at 08:18:46AM +0200, Thomas Gleixner wrote:
> > > Which other two? The boot optional removal patches? They just remove
> > > the visible interface, but keep the implementation which is converted
> >
On Mon, 28 May 2018, Christoph Hellwig wrote:
> On Mon, May 28, 2018 at 08:23:35AM +0200, Thomas Gleixner wrote:
> > > > They remove the commandline switch before having the replacement in
> > > > place
> > > > unless I'm misreading something.
> >
On Wed, 13 Jun 2018, Julien Thierry wrote:
> On 13/06/18 09:34, Peter Zijlstra wrote:
> > On Tue, Jun 12, 2018 at 05:57:23PM -0700, Ricardo Neri wrote:
> > > diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> > > index 5426627..dbc5e02 100644
> > > --- a/include/linux/interrupt.h
On Wed, 13 Jun 2018, Peter Zijlstra wrote:
> On Wed, Jun 13, 2018 at 05:41:41PM +1000, Nicholas Piggin wrote:
> > On Tue, 12 Jun 2018 17:57:32 -0700
> > Ricardo Neri wrote:
> >
> > > Instead of exposing individual functions for the operations of the NMI
> > > watchdog, define a common interface t
On Tue, 12 Jun 2018, Ricardo Neri wrote:
> @@ -183,6 +184,8 @@ static irqreturn_t hardlockup_detector_irq_handler(int
> irq, void *data)
> if (!(hdata->flags & HPET_DEV_PERI_CAP))
> kick_timer(hdata);
>
> + pr_err("This interrupt should not have happened. Ensure delivery
On Tue, 12 Jun 2018, Ricardo Neri wrote:
> + /* There are no CPUs to monitor. */
> + if (!cpumask_weight(&hdata->monitored_mask))
> + return NMI_HANDLED;
> +
> inspect_for_hardlockups(regs);
>
> + /*
> + * Target a new CPU. Keep trying until we find a monitored
On Wed, 13 Jun 2018, Julien Thierry wrote:
> On 13/06/18 10:20, Thomas Gleixner wrote:
> > Adding NMI delivery support at low level architecture irq chip level is
> > perfectly fine, but the exposure of that needs to be restricted very
> > much. Adding it to the gene
On Thu, 14 Jun 2018, Nicholas Piggin wrote:
> On Wed, 13 Jun 2018 18:31:17 -0700
> > I could look into creating the library for
> > common code and relocate the hpet watchdog into arch/x86 for the hpet-
> > specific parts.
>
> If you can investigate that approach, that would be appreciated. I hope
On Thu, 14 Jun 2018, Ricardo Neri wrote:
> On Wed, Jun 13, 2018 at 11:40:00AM +0200, Thomas Gleixner wrote:
> > On Tue, 12 Jun 2018, Ricardo Neri wrote:
> > > @@ -183,6 +184,8 @@ static irqreturn_t
> > > hardlockup_detector_irq_handler(int irq, void *data)
On Thu, 14 Jun 2018, Ricardo Neri wrote:
> On Wed, Jun 13, 2018 at 11:48:09AM +0200, Thomas Gleixner wrote:
> > On Tue, 12 Jun 2018, Ricardo Neri wrote:
> > > + /* There are no CPUs to monitor. */
> > > + if (!cpumask_weight(&hdata->monitored_mask))
On Fri, 15 Jun 2018, Ricardo Neri wrote:
> On Fri, Jun 15, 2018 at 11:19:09AM +0200, Thomas Gleixner wrote:
> > On Thu, 14 Jun 2018, Ricardo Neri wrote:
> > > Alternatively, there could be a counter that skips reading the HPET status
> > > register (and the detection
On Fri, 15 Jun 2018, Ricardo Neri wrote:
> On Fri, Jun 15, 2018 at 12:29:06PM +0200, Thomas Gleixner wrote:
> > You have to consider two cases:
> >
> > 1) !remapped mode:
> >
> > That's reasonably simple because you just have to deal with the HPET
>
On Fri, 15 Jun 2018, Ricardo Neri wrote:
> On Fri, Jun 15, 2018 at 09:01:02AM +0100, Julien Thierry wrote:
> > In my patches, I'm not sure there is much to adapt to your work as most of
> > it is arch specific (although I wont say no to another pair of eyes looking
> > at them). From what I've seen
On Tue, 19 Jun 2018, Ricardo Neri wrote:
> On Sat, Jun 16, 2018 at 03:24:49PM +0200, Thomas Gleixner wrote:
> > The status register is useless in case of MSI. MSI is edge triggered
> >
> > The only register which gives you proper information is the counter
> > re
On Mon, 30 Jul 2018, Christoph Hellwig wrote:
> There is nothing arch specific about PCI or dma-debug, so move this
> call to common code just after registering the bus type.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Thomas Gleixner
_
n the posted bit fields
with different meanings.
Extend struct irte to handle the differences between remap and posted
mode by having three structs in the unions:
- Shared
- Remapped
- Posted
Signed-off-by: Thomas Gleixner
---
include/linux/dmar.h | 68
On Thu, 21 May 2015, Feng Wu wrote:
> +static int intel_ir_set_vcpu_affinity(struct irq_data *data, void *vcpu_info)
> +{
> + struct intel_ir_data *ir_data = data->chip_data;
> + struct irte *irte_pi = &ir_data->irte_pi_entry;
> + struct vcpu_data *vcpu_pi_info;
> +
> + /* stop post
On Thu, 21 May 2015, Feng Wu wrote:
> @@ -647,6 +647,20 @@ static int __init intel_enable_irq_remapping(void)
> + /*
> + * Set Posted-Interrupts capability.
> + */
> + if (!disable_irq_post) {
> + intel_irq_remap_ops.capability |= 1 << IRQ_POSTING_CAP;
> +
> +
On Mon, 25 May 2015, Feng Wu wrote:
> We don't need to migrate the irqs for VT-d Posted-Interrupts here.
> When 'pst' is set in IRTE, the associated irq will be posted to
> guests instead of interrupt remapping. The destination of the
> interrupt is set in Posted-Interrupts Descriptor, and the mig
On Tue, 26 May 2015, Wu, Feng wrote:
> > On Mon, 25 May 2015, Feng Wu wrote:
> > > +
> > > + /* We don't need to modify irte if the interrupt is for posting. */
> > > + if (irte->pst != 1)
> > > + modify_irte(&ir_data->irq_2_iommu, irte);
> >
> > I don't think this is correct. ir_data->irt
On Wed, 27 May 2015, Feng Wu wrote:
> + /* stop posting interrupts, back to remapping mode */
> + if (!vcpu_info) {
> + modify_irte(&ir_data->irq_2_iommu, &ir_data->irte_entry);
> + } else {
> + vcpu_pi_info = (struct vcpu_data *)vcpu_info;
> +
> + /*
On Fri, 5 Jun 2015, Feng Wu wrote:
> Divide the whole series which contain multiple components into three parts:
> - Prerequisite changes to irq subsystem (already merged in tip tree x86/apic
> branch)
> - IOMMU part (in this series)
Please add
Reviewed-by: Thomas Gleixner
Which
On Fri, 26 Feb 2016, Eric Auger wrote:
> Let's introduce a new msi_domain_info flag value, MSI_FLAG_IRQ_REMAPPING
> meant to tell the domain supports IRQ REMAPPING, also known as Interrupt
> Translation Service. On Intel HW this capability is abstracted on IOMMU
> side while on ARM it is abstracte
On Fri, 26 Feb 2016, Eric Auger wrote:
> +static int msi_map_doorbell(struct iommu_domain *d, struct msi_msg *msg)
> +{
> +#ifdef CONFIG_IOMMU_DMA_RESERVED
> + dma_addr_t iova;
> + phys_addr_t addr;
> + int ret;
> +
> +#ifdef CONFIG_PHYS_ADDR_T_64BIT
> + addr = ((phys_addr_t)(msg->a
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
501 - 584 of 584 matches
Mail list logo
