Geetha,
On 20/12/16 11:06, Geetha sowjanya wrote:
> From: Tirumalesh Chalamarla
>
> This patch implements Cavium ThunderX erratum 28168.
>
> PCI requires stores complete in order. Due to erratum #28168
> PCI-inbound MSI-X store to the interrupt controller are delivered
> to the interrup
Hi Eric,
On 04/01/17 13:32, Eric Auger wrote:
> This new function checks whether all platform and PCI
> MSI domains implement IRQ remapping. This is useful to
> understand whether VFIO passthrough is safe with respect
> to interrupts.
>
> On ARM typically an MSI controller can sit downstream
> to
On 04/01/17 14:11, Auger Eric wrote:
> Hi Marc,
>
> On 04/01/2017 14:46, Marc Zyngier wrote:
>> Hi Eric,
>>
>> On 04/01/17 13:32, Eric Auger wrote:
>>> This new function checks whether all platform and PCI
>>> MSI domains implement IRQ remapping.
On 05/01/17 10:45, Auger Eric wrote:
> Hi Marc,
>
> On 04/01/2017 16:27, Marc Zyngier wrote:
>> On 04/01/17 14:11, Auger Eric wrote:
>>> Hi Marc,
>>>
>>> On 04/01/2017 14:46, Marc Zyngier wrote:
>>>> Hi Eric,
>>>>
>>>&g
On 05/01/17 11:29, Auger Eric wrote:
> Hi Marc,
>
> On 05/01/2017 12:25, Marc Zyngier wrote:
>> On 05/01/17 10:45, Auger Eric wrote:
>>> Hi Marc,
>>>
>>> On 04/01/2017 16:27, Marc Zyngier wrote:
>>>> On 04/01/17 14:11, Auger Eric wrote:
>&g
On 06/01/17 09:08, Auger Eric wrote:
> Hi Bharat
>
> On 06/01/2017 09:50, Bharat Bhushan wrote:
>> Hi Eric,
>>
>>> -Original Message-
>>> From: Eric Auger [mailto:eric.au...@redhat.com]
>>> Sent: Friday, January 06, 2017 12:35 AM
>>> To: eric.au...@redhat.com; eric.auger@gmail.com;
>>>
On 06/01/17 04:27, Bharat Bhushan wrote:
> Hi Mark,
>
>> -Original Message-
>> From: Auger Eric [mailto:eric.au...@redhat.com]
>> Sent: Thursday, January 05, 2017 5:39 PM
>> To: Marc Zyngier ; eric.auger@gmail.com;
>> christoffer.d...@linaro.org; r
Hi Eric,
On 09/01/17 13:46, Eric Auger wrote:
> We introduce two new enum values for the irq domain flag:
> - IRQ_DOMAIN_FLAG_MSI indicates the irq domain corresponds to
> an MSI domain
> - IRQ_DOMAIN_FLAG_MSI_REMAP indicates the irq domain has MSI
> remapping capabilities.
>
> Those values w
On 09/01/17 13:46, Eric Auger wrote:
> This new function checks whether all MSI irq domains
> implement IRQ remapping. This is useful to understand
> whether VFIO passthrough is safe with respect to interrupts.
>
> On ARM typically an MSI controller can sit downstream
> to the IOMMU without preven
a = its;
> inner_domain->host_data = info;
>
For patches 13 to 16, and provided that you address the couple of nits I
mentioned in reply to patches 13 and 15:
Reviewed-by: Marc Zyngier
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_
On 30/05/17 17:49, Ray Jui wrote:
> Hi Will,
>
> On 5/30/17 8:14 AM, Will Deacon wrote:
>> On Mon, May 29, 2017 at 06:18:45PM -0700, Ray Jui wrote:
>>> I'm writing to check with you to see if the latest arm-smmu.c driver in
>>> v4.12-rc Linux for smmu-500 can support mapping that is only specific
On 30/05/17 18:16, Ray Jui wrote:
> Hi Marc,
>
> On 5/30/17 9:59 AM, Marc Zyngier wrote:
>> On 30/05/17 17:49, Ray Jui wrote:
>>> Hi Will,
>>>
>>> On 5/30/17 8:14 AM, Will Deacon wrote:
>>>> On Mon, May 29, 2017 at 06:18:45PM -0700, Ray Jui wr
On 21/06/17 10:08, Will Deacon wrote:
> Hi Geetha,
>
> On Wed, Jun 21, 2017 at 12:09:45PM +0530, Geetha Akula wrote:
>> On Tue, Jun 20, 2017 at 11:30 PM, Will Deacon wrote:
>>> On Tue, Jun 20, 2017 at 07:47:39PM +0530, Geetha sowjanya wrote:
From: Geetha Sowjanya
Cavium ThunderX2
On 08/04/14 14:41, Laurent Pinchart wrote:
> I've obviously forgotten that Will was away for a month. CC'ing Marc Zyngier.
>
> On Thursday 03 April 2014 01:52:55 Laurent Pinchart wrote:
>> On Friday 28 February 2014 16:37:08 Laurent Pinchart wrote:
>>> Hello W
On 01/05/14 15:36, Dave Martin wrote:
> On Thu, May 01, 2014 at 02:29:50PM +0100, Arnd Bergmann wrote:
>> On Thursday 01 May 2014 12:15:35 Dave Martin wrote:
>>> On Tue, Apr 29, 2014 at 10:46:18PM +0200, Arnd Bergmann wrote:
On Tuesday 29 April 2014 19:16:02 Dave Martin wrote:
>>>
>>> [...]
>>
On 01/05/14 16:53, Arnd Bergmann wrote:
> On Thursday 01 May 2014 16:11:48 Marc Zyngier wrote:
>> On 01/05/14 15:36, Dave Martin wrote:
>>> On Thu, May 01, 2014 at 02:29:50PM +0100, Arnd Bergmann wrote:
>>>> On Thursday 01 May 2014 12:15:35 Dave Martin wrote:
>&
On Fri, Jun 27 2014 at 10:57:28 PM, "Chalamarla, Tirumalesh"
wrote:
> Marc,
>
> What is your opinion on ITS emulation . is it should be part
> of KVM or VFIO.
Making any sort of emulation part of VFIO sounds quite wrong. That's not
what VFIO is about, at all. Emulation belongs
Hi John,
On 2020-03-20 16:20, John Garry wrote:
I've run a bunch of netperf instances on multiple cores and
collecting
SMMU usage (on TaiShan 2280). I'm getting the following ratio pretty
consistently.
- 6.07% arm_smmu_iotlb_sync
- 5.74% arm_smmu_tlb_inv_range
5.09% arm_smmu
On 2020-03-23 09:03, John Garry wrote:
On 20/03/2020 16:33, Marc Zyngier wrote:
JFYI, I've been playing for "perf annotate" today and it's giving
strange results for my NVMe testing. So "report" looks somewhat sane,
if not a worryingly high % for arm_smmu_cmdq_issu
On Tue, 24 Mar 2020 09:18:10 +
John Garry wrote:
> On 23/03/2020 09:16, Marc Zyngier wrote:
>
> + Julien, Mark
>
> Hi Marc,
>
> >>> Time to enable pseudo-NMIs in the PMUv3 driver...
> >>>
> >>
> >> Do you know if there is any p
On 2020-05-21 15:17, Will Deacon wrote:
[+Marc]
On Tue, May 19, 2020 at 07:54:51PM +0200, Jean-Philippe Brucker wrote:
The SMMUv3 can handle invalidation targeted at TLB entries with shared
ASIDs. If the implementation supports broadcast TLB maintenance,
enable it
and keep track of it in a fea
Hi John,
+Will for the SMMU part.
On 2020-06-16 07:13, John Stultz wrote:
Allow the qcom_scm driver to be loadable as a
permenent module.
Cc: Andy Gross
Cc: Bjorn Andersson
Cc: Joerg Roedel
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
Cc: Linus Walleij
Cc: Lina Iyer
Cc
Hi Baptiste,
On 26/02/15 17:02, Baptiste Reynal wrote:
> Hi everyone,
>
> Are there any comments on this patch series? If not, Is there
> anything keeping this series from getting merged upstream?
For a start, it looks like the dependency mentioned below is still not
in, which is a bit of a prob
t; 0))
return ret;
if (WARN_ON(clk_bulk_enable(iommu->num_clocks, iommu->clocks)))
Acked-by: Marc Zyngier
M.
--
Jazz is not dead. It just smells funny...
___
iommu mailing list
iommu@lists.linux-foundation.org
https:
On 19/04/16 18:13, Eric Auger wrote:
> The purpose is to be able to retrieve the MSI doorbells of an irqchip.
> This is now needed since on some platforms those doorbells must be
> iommu mapped (in case the MSIs transit through an IOMMU that do not
> bypass those transactions).
>
> The assumption
On 19/04/16 18:13, Eric Auger wrote:
> This patch implements the msi_doorbell_info callback in the
> gicv2m driver.
>
> The driver now is able to return its doorbell characteristics
> (base, size, prot). A single doorbell is exposed.
>
> This will allow the msi layer to iommu_map this doorbell wh
On 19/04/16 17:56, Eric Auger wrote:
> Introduce iommu_msi_mapping_translate_msg whose role consists in
> detecting whether the device's MSIs must to be mapped into an IOMMU.
> It case it must, the function overrides the MSI msg originally composed
> and replaces the doorbell's PA by a pre-allocate
On 19/04/16 18:13, Eric Auger wrote:
> On MSI message composition we now use the MSI doorbell's IOVA in
> place of the doorbell's PA in case the device is upstream to an
> IOMMU that requires MSI addresses to be mapped. The doorbell's
> allocation and mapping happened on an early stage (pci_enable_
On Wed, 20 Apr 2016 14:33:17 +0200
Eric Auger wrote:
> Marc,
> On 04/20/2016 11:27 AM, Marc Zyngier wrote:
> > On 19/04/16 18:13, Eric Auger wrote:
> >> This patch implements the msi_doorbell_info callback in the
> >> gicv2m driver.
> >>
> >&g
On 28/04/16 09:22, Eric Auger wrote:
> The purpose is to be able to retrieve the MSI doorbells of an irqchip.
> This is now needed since on some platforms those doorbells must be
> iommu mapped (in case the MSIs transit through an IOMMU that do not
> bypass those transactions).
>
> The assumption
On 28/04/16 09:22, Eric Auger wrote:
> This patch implements the msi_doorbell_info callback in the
> gicv2m driver.
>
> The driver now is able to return its doorbell characteristics
> (base, size, prot). A single doorbell is exposed.
>
> This will allow the msi layer to iommu_map this doorbell wh
On 28/04/16 09:22, Eric Auger wrote:
> This patch handles the iommu mapping of MSI doorbells that require to
> be mapped in an iommu domain. This happens on msi_domain_alloc/free_irqs
> since this is called in code that can sleep (pci_enable/disable_msi):
> iommu_map/unmap is not stated as atomic.
On 28/04/16 09:22, Eric Auger wrote:
> On MSI message composition we now use the MSI doorbell's IOVA in
> place of the doorbell's PA in case the device is upstream to an
> IOMMU that requires MSI addresses to be mapped. The doorbell's
> allocation and mapping happened on an early stage (pci_enable_
sing routine up yet another layer into the general OF-PCI code,
> and further generalise it for either kind of lookup in either flavour
> of map property.
>
> CC: Rob Herring
> CC: Frank Rowand
> CC: Marc Zyngier
> Signed-off-by: Robin Murphy
Acked-by: Marc Zyngier
vice attached to one of our DMA
> ops domains.
>
> CC: Thomas Gleixner
> CC: Jason Cooper
> CC: Marc Zyngier
> CC: linux-ker...@vger.kernel.org
> Signed-off-by: Robin Murphy
Thanks for the quick respin.
Acked-by: Marc Zyngier
Geetha,
On 22/10/16 05:54, Geetha sowjanya wrote:
> From: Tirumalesh Chalamarla
>
> This patch implements Cavium ThunderX erratum 28168.
>
> PCI requires stores complete in order. Due to erratum #28168
> PCI-inbound MSI-X store to the interrupt controller are delivered
> to the interrup
On 15/11/16 07:00, Geetha sowjanya wrote:
> From: Tirumalesh Chalamarla
>
> This patch implements Cavium ThunderX erratum 28168.
>
> PCI requires stores complete in order. Due to erratum #28168
> PCI-inbound MSI-X store to the interrupt controller are delivered
> to the interrupt control
On 15/11/16 18:24, David Daney wrote:
> On 11/15/2016 01:26 AM, Marc Zyngier wrote:
>> On 15/11/16 07:00, Geetha sowjanya wrote:
>>> From: Tirumalesh Chalamarla
>>>
>>>This patch implements Cavium ThunderX erratum 28168.
>>>
>>>PCI re
On 17/08/17 08:58, Joerg Roedel wrote:
> On Thu, Aug 17, 2017 at 03:02:31PM +0800, Shawn Lin wrote:
>> So should we revert this commit or maybe we could add some checking
>> into gic-v2m and gic-v3-its to see if the dev is iommu-capable? If not,
>> we should create another routine to map MSI msg.
>
On 17/08/17 09:28, Shawn Lin wrote:
> If a PCIe RC use gic-v2m or gic-v3-its as a msi domain but doesn't
> have iommu support, we don't need to do iommu_dma_map_msi_msg to
> get mapped iommu address as all we need is the physical address.
> Otherwise we see the oops shown below as we can't get a io
On 17/08/17 10:01, Shawn Lin wrote:
> Hi Marc
>
> On 2017/8/17 16:52, Marc Zyngier wrote:
>> On 17/08/17 09:28, Shawn Lin wrote:
>>> If a PCIe RC use gic-v2m or gic-v3-its as a msi domain but doesn't
>>> have iommu support, we don't need to do iommu_dma_
> looking rather familiar, but now it's backed by the reasoning of having
> a robust API able to do the expected thing for all devices regardless.
>
> Fixes: 05f80300dc8b ("iommu: Finish making iommu_group support mandatory")
> Reported-by: Shawn Lin
> Signed-off-
On 27/09/17 14:32, Shameer Kolothum wrote:
> From: John Garry
>
> On some platforms msi-controller address regions have to be excluded
> from normal IOVA allocation in that they are detected and decoded in
> a HW specific way by system components and so they cannot be considered
> normal IOVA add
On 27/09/17 14:32, Shameer Kolothum wrote:
> On some platforms msi parent address regions have to be excluded from
> normal IOVA allocation in that they are detected and decoded in a HW
> specific way by system components and so they cannot be considered normal
> IOVA address space.
>
> Add a help
nclude/linux/acpi_iort.h| 7 ++-
> 3 files changed, 116 insertions(+), 5 deletions(-)
For the ITS part:
Reviewed-by: Marc Zyngier
M.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 17/01/18 18:54, Robin Murphy wrote:
> [ +Marc just in case ]
>
> On 17/01/18 18:39, Nate Watterson wrote:
>> From: Sinan Kaya
>>
>> Even though QDF2400 supports MSI interrupts with SMMUv3, it is not enabled
>> in ACPI FW to preserve compatibility with older kernel versions. Code is
>> emitting
dev_warn(dev, "failed to allocate MSIs\n");
> + dev_warn(dev, "failed to allocate MSIs - falling back to wired
> irqs\n");
> return;
> }
>
>
Acked-by: Marc Zyngier
M.
--
Jazz is not dead. It just smells funny...
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
azy behind our back. Note that we need to be
extra cautious when doing so, as the IOMMU may not be clocked
if controlled by a another master, as typical on Rockchip system.
Suggested-by: Robin Murphy
Signed-off-by: Marc Zyngier
---
drivers/iommu/rockchip-iommu.c | 18 ++
1 file c
On 2018-03-28 15:39, Timur Tabi wrote:
From: Sameer Goel
Set SMMU_GBPA to abort all incoming translations during the SMMU
reset
when SMMUEN==0.
This prevents a race condition where a stray DMA from the crashed
primary
kernel can try to access an IOVA address as an invalid PA when SMMU
is
Hi Sammer,
On 11/04/18 16:58, Goel, Sameer wrote:
>
>
> On 3/28/2018 9:00 AM, Marc Zyngier wrote:
>> On 2018-03-28 15:39, Timur Tabi wrote:
>>> From: Sameer Goel
>>>
>>> Set SMMU_GBPA to abort all incoming translations during the SMMU reset
>&g
On 12/04/18 11:17, Robin Murphy wrote:
> On 11/04/18 17:54, Marc Zyngier wrote:
>> Hi Sammer,
>>
>> On 11/04/18 16:58, Goel, Sameer wrote:
>>>
>>>
>>> On 3/28/2018 9:00 AM, Marc Zyngier wrote:
>>>> On 2018-03-28 15:39, Timur Tabi wrote:
Hi Vincent,
On 10/04/2019 13:35, Vincent Stehlé wrote:
> On Thu, Apr 04, 2019 at 08:55:25AM +0200, Auger Eric wrote:
>> Hi Marc, Robin, Alex,
> (..)
>> Do you think this is a reasonable assumption to consider devices within
>> the same host iommu group share the same MSI doorbell?
>
> Hi Eric,
>
Hi Julien,
On 18/04/2019 18:26, Julien Grall wrote:
> When an MSI doorbell is located downstream of an IOMMU, it is required
> to swizzle the physical address with an appropriately-mapped IOVA for any
> device attached to one of our DMA ops domain.
>
> At the moment, the allocation of the mapping
On 18/04/2019 18:26, Julien Grall wrote:
> On RT, the function iommu_dma_map_msi_msg may be called from
> non-preemptible context. This will lead to a splat with
> CONFIG_DEBUG_ATOMIC_SLEEP as the function is using spin_lock
> (they can sleep on RT).
>
> The function iommu_dma_map_msi_msg is used
On 23/04/2019 11:51, Julien Grall wrote:
> On 4/23/19 11:23 AM, Marc Zyngier wrote:
>> Hi Julien,
>
> Hi Marc,
>
>> On 18/04/2019 18:26, Julien Grall wrote:
>>> When an MSI doorbell is located downstream of an IOMMU, it is required
>>> to swizzle the phy
On 23/04/2019 14:19, Robin Murphy wrote:
> On 23/04/2019 12:46, Marc Zyngier wrote:
>> On 23/04/2019 11:51, Julien Grall wrote:
>>> On 4/23/19 11:23 AM, Marc Zyngier wrote:
>>>> Hi Julien,
>>>
>>> Hi Marc,
>>>
>>>> On 18/04/
On 29/04/2019 15:44, Julien Grall wrote:
> On RT, iommu_dma_map_msi_msg() may be called from non-preemptible
> context. This will lead to a splat with CONFIG_DEBUG_ATOMIC_SLEEP as
> the function is using spin_lock (they can sleep on RT).
>
> iommu_dma_map_msi_msg() is used to map the MSI page in t
Hi Julien,
On 29/04/2019 15:44, Julien Grall wrote:
> Hi all,
>
> On RT, the function iommu_dma_map_msi_msg expects to be called from
> preemptible
> context. However, this is not always the case resulting a splat with
> !CONFIG_DEBUG_ATOMIC_SLEEP:
>
> [ 48.875777] BUG: sleeping function call
On 01/05/2019 12:14, Julien Grall wrote:
> On 30/04/2019 13:34, Auger Eric wrote:
>> Hi Julien,
>
> Hi Eric,
>
> Thank you for the review!
>
>>
>> On 4/29/19 4:44 PM, Julien Grall wrote:
>>> its_irq_compose_msi_msg() may be called from non-preemptible context.
>>> However, on RT, iommu_dma_map_m
On 01/05/2019 14:58, Julien Grall wrote:
> The functions mbi_compose_m{b, s}i_msg may be called from non-preemptible
> context. However, on RT, iommu_dma_map_msi_msg() requires to be called
> from a preemptible context.
>
> A recent patch split iommu_dma_map_msi_msg in two new functions:
> one tha
business with a bnx2x device passed
to a guest. FWIW:
Tested-by: Marc Zyngier
Thanks,
M.
--
Jazz is not dead. It just smells funny...
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Sat, 27 Jun 2020 02:34:25 +0100,
John Stultz wrote:
>
> On Fri, Jun 26, 2020 at 12:42 AM Stephen Boyd wrote:
> >
> > Quoting John Stultz (2020-06-24 17:10:37)
> > > diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
> > > index 6ae9e1f0819d..3fee8b655da1 100644
> > > --- a/d
On Sat, 11 Jul 2020 00:27:45 +0100,
Stephen Boyd wrote:
>
> Quoting John Stultz (2020-07-10 15:44:18)
> > On Thu, Jul 9, 2020 at 11:02 PM Stephen Boyd wrote:
> > >
> > > Does it work? I haven't looked in detail but I worry that the child
> > > irqdomain (i.e. pinctrl-msm) would need to delay pro
++--
drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 15 +-
5 files changed, 47 insertions(+), 40 deletions(-)
For this patch and the following one:
Acked-by: Marc Zyngier
M.
--
Jazz is not dead. It just smells funny...
___
iommu mailing
On 2020-07-16 04:23, Makarand Pawagi wrote:
-Original Message-
From: Lorenzo Pieralisi
[...]
Anyway - you need to seek feedback from Marc on whether patches
11 and 12 are OK from an irqchip perspective, it is possible we can
take the rest
of the series independently if everyone agre
On Fri, 10 Jul 2020 23:18:21 +, John Stultz wrote:
> This patch series provides exports and config tweaks to allow
> the qcom-pdc driver to be able to be configured as a permement
> modules (particularlly useful for the Android Generic Kernel
> Image efforts).
>
> This was part of a larger pat
irqs(struct irq_dom
> }
>
> /**
> + * __msi_domain_free_irqs - Free interrupts from a MSI interrupt @domain
> associated tp @dev
Spurious __.
> + * @domain: The domain to managing the interrupts
> + * @dev: Pointer to device struct of the device for which the inter
100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -1544,7 +1544,7 @@ int irq_chip_compose_msi_msg(struct irq_data *data,
struct msi_msg *msg)
struct irq_data *pos = NULL;
#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
- for (; data; data = data->parent_data)
+ for (; data &&a
msi_prepare);
>
> -void pci_msi_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc)
> -{
> - arg->desc = desc;
> - arg->hwirq = pci_msi_domain_calc_hwirq(desc);
> -}
> -EXPORT_SYMBOL_GPL(pci_msi_set_desc);
I think that at this stage, pci_msi_domain_calc_hwirq() can be made
On Wed, 26 Aug 2020 12:16:45 +0100,
Thomas Gleixner wrote:
>
> From: Thomas Gleixner
>
> Retrieve the PCI device from the msi descriptor instead of doing so at the
> call sites.
>
> Signed-off-by: Thomas Gleixner
> Acked-by: Bjorn Helgaas
Acked-by: Marc Zyngier
ch(domain->bus_token) {
> + case DOMAIN_BUS_PCI_MSI:
> + case DOMAIN_BUS_VMD_MSI:
> + break;
> + default:
> return false;
> + }
>
> if (!(info->flags & MSI_FLAG_MUST_REACTIVATE))
> return false;
Acked-by: Mar
MSI domain.
> + */
> + irq_domain_update_bus_token(vmd->irq_domain, DOMAIN_BUS_VMD_MSI);
> +
One day, we'll be able to set the token at domain creation time. In
the meantime,
Acked-by: Marc Zyngier
M.
--
Without deviation from the norm, progress is not po
here if you want kernel to support the Xilinx AXI PCIe
@@ -105,7 +106,6 @@ config PCIE_XILINX_CPM
bool "Xilinx Versal CPM host bridge support"
depends on ARCH_ZYNQMP || COMPILE_TEST
select PCI_HOST_COMMON
- select PCI_MSI_ARCH_FA
_mask = irq_chip_mask_parent;
> if (!chip->irq_unmask)
> chip->irq_unmask = irq_chip_unmask_parent;
> + if (!chip->irq_ack)
> + chip->irq_ack = irq_chip_ack_parent;
> if (!chip->irq_eoi)
> chip->irq_eoi = irq_
On Wed, 26 Aug 2020 22:19:56 +0100,
Thomas Gleixner wrote:
>
> On Wed, Aug 26 2020 at 20:50, Marc Zyngier wrote:
> > On Wed, 26 Aug 2020 12:16:32 +0100,
> > Thomas Gleixner wrote:
> >> ---
> >> V2: New patch. Note, that this might break other stuff which reli
On Wed, 26 Aug 2020 20:47:38 +0100,
Thomas Gleixner wrote:
>
> On Wed, Aug 26 2020 at 20:06, Marc Zyngier wrote:
> > On Wed, 26 Aug 2020 12:16:57 +0100,
> > Thomas Gleixner wrote:
> >> /**
> >> - * msi_domain_free_irqs - Free interrupts from a MSI interr
On 2020-08-26 12:17, Thomas Gleixner wrote:
MSI interrupts have some common flags which should be set not only for
PCI/MSI interrupts.
Move the PCI/MSI flag setting into a common function so it can be
reused.
Signed-off-by: Thomas Gleixner
---
V2: New patch
---
drivers/pci/msi.c |7 +-
Hi Jason,
On 2020-08-28 13:19, Jason Gunthorpe wrote:
On Fri, Aug 28, 2020 at 12:21:42PM +0100, Lorenzo Pieralisi wrote:
On Thu, Aug 27, 2020 at 01:20:40PM -0500, Bjorn Helgaas wrote:
[...]
> And I can't figure out what's special about tegra, rcar, and xilinx
> that makes them need it as well
On 2020-08-28 13:54, Jason Gunthorpe wrote:
On Fri, Aug 28, 2020 at 01:47:59PM +0100, Marc Zyngier wrote:
> So the arch_setup_msi_irq/etc is not really an arch hook, but some
> infrastructure to support those 4 PCI root port drivers.
I happen to have a *really old* patch addressing Te
On Tue, 22 Mar 2022 17:27:36 +,
Robin Murphy wrote:
>
> Originally, creating the dma_ranges resource list in pre-sorted fashion
> was the simplest and most efficient way to enforce the order required by
> iova_reserve_pci_windows(). However since then at least one PCI host
> driver is now re-
On 2022-04-22 22:17, Linus Walleij wrote:
On Thu, Apr 21, 2022 at 9:42 AM Christoph Hellwig wrote:
arm is the last platform not using the dma-direct code for directly
mapped DMA. With the dmaboune removal from Arnd we can easily switch
arm to always use dma-direct now (it already does for LPA
hat he can test this on. Marc?
> I have one too, just not much in my office because of parental leave.
Finally found some time to hook the machine up and throw a new kernel
at it. Booted at its usual glacial speed, so FWIW:
Tested-by: Marc Zyn
Hi Shameer,
[+Will]
On Mon, 22 Feb 2021 15:53:36 +,
Shameer Kolothum wrote:
>
> On an ARM64 system with a SMMUv3 implementation that fully supports
> Broadcast TLB Maintenance(BTM) feature, the CPU TLB invalidate
> instructions are received by SMMU. This is very useful when the
> SMMU share
On Fri, 26 Feb 2021 20:11:11 +,
Megha Dey wrote:
>
> From: Thomas Gleixner
>
> For devices which don't have a standard storage for MSI messages like the
> upcoming IMS (Interrupt Message Store) it's required to allocate storage
> space before allocating interrupts and after freeing them.
>
On Fri, 26 Feb 2021 20:11:12 +,
Megha Dey wrote:
>
> Introduce a new function pointer in the irq_chip structure(irq_set_auxdata)
> which is responsible for updating data which is stored in a shared register
> or data storage. For example, the idxd driver uses the auxiliary data API
> to enabl
On Fri, 26 Feb 2021 20:11:16 +,
Megha Dey wrote:
>
> Generic IMS(Interrupt Message Store) irq chips and irq domain
> implementations for IMS based devices which store the interrupt messages
> in an array in device memory.
>
> Allocation and freeing of interrupts happens via the generic
> msi
On Fri, 26 Feb 2021 20:11:17 +,
Megha Dey wrote:
>
> From: Dave Jiang
>
> Add new helpers to get the Linux IRQ number and device specific index
> for given device-relative vector so that the drivers don't need to
> allocate their own arrays to keep track of the vectors and hwirq for
> the m
On Thu, 25 Mar 2021 18:44:48 +,
Thomas Gleixner wrote:
>
> On Thu, Mar 25 2021 at 17:08, Marc Zyngier wrote:
> > Megha Dey wrote:
> >> @@ -434,6 +434,12 @@ int __msi_domain_alloc_irqs(struct irq_domain
> >> *domain, struct device *dev,
> >>
On Thu, 25 Mar 2021 18:59:48 +,
Thomas Gleixner wrote:
>
> On Thu, Mar 25 2021 at 17:23, Marc Zyngier wrote:
> >> +{
> >> + struct irq_desc *desc;
> >> + struct irq_data *data;
> >> + unsigned long flags;
> >> + int res = -ENODEV;
> &
On Fri, 26 Mar 2021 01:02:43 +,
"Dey, Megha" wrote:
>
> Hi Marc,
>
> On 3/25/2021 10:53 AM, Marc Zyngier wrote:
> > On Fri, 26 Feb 2021 20:11:17 +,
> > Megha Dey wrote:
> >> From: Dave Jiang
> >>
> >> Add new helpers t
On Fri, 23 Apr 2021 18:58:23 +0100,
Krishna Reddy wrote:
>
> >> Did that patch cause any issue, or is it just not needed on your system?
> >> It fixes an hypothetical problem with the way ATS is implemented.
> >> Maybe I actually observed it on an old software model, I don't
> >> remember. Eith
On Tue, 29 Jun 2021 18:34:40 +0100,
Will Deacon wrote:
>
> On Fri, Jun 18, 2021 at 05:24:49PM +0100, Robin Murphy wrote:
> > Arm Fast Models are still implementing legacy virtio-pci devices behind
> > the SMMU, which continue to be problematic as "real hardware" devices
> > (from the point of vie
On Wed, 21 Jul 2021 12:42:14 +0100,
Robin Murphy wrote:
>
> [ +Marc for MSI bits ]
>
> On 2021-07-21 02:33, Bixuan Cui wrote:
> > Add suspend and resume support for arm-smmu-v3 by low-power mode.
> >
> > When the smmu is suspended, it is powered off and the registers are
> > cleared. So saves t
On Wed, 21 Jul 2021 14:59:47 +0100,
Robin Murphy wrote:
>
> On 2021-07-21 14:12, Marc Zyngier wrote:
> > On Wed, 21 Jul 2021 12:42:14 +0100,
> > Robin Murphy wrote:
> >>
> >> [ +Marc for MSI bits ]
> >>
> >> On 2021-07-21 02:33, Bixuan C
On 2021-07-22 12:12, John Garry wrote:
Hi John,
[...]
Your kernel log should show:
[0.00] GICv3: Pseudo-NMIs enabled using forced ICC_PMR_EL1
synchronisation
Unrelated, but you seem to be running with ICC_CTLR_EL3.PMHE set,
which makes the overhead of pseudo-NMIs much higher
On Tue, 27 Jul 2021 13:14:08 +0100,
Bixuan Cui wrote:
>
> Add suspend and resume support for arm-smmu-v3 by low-power mode.
>
> When the smmu is suspended, it is powered off and the registers are
> cleared. So saves the msi_msg context during msi interrupt initialization
> of smmu. When resume h
iommu_group_release+0x68/0xac
>kobject_cleanup+0x4c/0x1fc
>kobject_cleanup+0x14c/0x1fc
>kobject_put+0x64/0x84
>iommu_group_remove_device+0x110/0x180
>iommu_release_device+0x50/0xa0
> [...]
>
> Fixes: 46d1fb072e76b161 ("iommu/dart: Add DART iommu driv
64bit pref]
> pci :03:00.0: BAR 6: assigned [mem 0x6c010-0x6c01007ff pref]
> tg3 :03:00.0: Failed to add to iommu group 1: -2
> [...]
>
> Fixes: 46d1fb072e76b161 ("iommu/dart: Add DART iommu driver")
> Reported-by: Marc Zyngier
> Signed-off-by: Sven Peter
t_name = irqchip_fwnode_get_name,
> +};
> EXPORT_SYMBOL_GPL(irqchip_fwnode_ops);
>
> /**
Acked-by: Marc Zyngier
--
Without deviation from the norm, progress is not possible.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 2020-11-12 21:34, Thomas Gleixner wrote:
On Thu, Nov 12 2020 at 20:15, Thomas Gleixner wrote:
The recent changes to store the MSI irqdomain pointer in struct device
missed that Intel DMAR does not register virtual function devices.
Due to
that a VF device gets the plain PCI-MSI domain assig
1 - 100 of 139 matches
Mail list logo
