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 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.
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
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
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 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
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
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
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
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_
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:
> 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:
> 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 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 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 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:
> 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 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 18/02/16 16:42, Eric Auger wrote:
> Hello,
> On 02/18/2016 12:06 PM, Marc Zyngier wrote:
>> On Fri, 12 Feb 2016 08:13:09 +
>> Eric Auger wrote:
>>
>>> This patch introduces iommu_get/put_single_reserved.
>>>
>>> iommu_get_single_reserved
On 18/02/16 15:33, Eric Auger wrote:
> Hi Marc,
> On 02/18/2016 12:33 PM, Marc Zyngier wrote:
>> On Fri, 12 Feb 2016 08:13:17 +
>> Eric Auger wrote:
>>
>>> In case the msi_desc references a device attached to an iommu
>>> domain, the msi address
On Fri, 12 Feb 2016 08:13:17 +
Eric Auger wrote:
> In case the msi_desc references a device attached to an iommu
> domain, the msi address needs to be mapped in the IOMMU. Else any
> MSI write transaction will cause a fault.
>
> gic_set_msi_addr detects that case and allocates an iova bound
On Fri, 12 Feb 2016 08:13:09 +
Eric Auger wrote:
> This patch introduces iommu_get/put_single_reserved.
>
> iommu_get_single_reserved allows to allocate a new reserved iova page
> and map it onto the physical page that contains a given physical address.
> It returns the iova that is mapped o
e/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 7d7a4c6..43e183b 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -400,6 +400,7 @@ struct vfio_iommu_type1_info {
> __u32 argsz;
> __u32 flags;
> #define VFIO_IOMMU_INFO_P
Despite being a platform device, the SMMUv3 is capable of signaling
interrupts using MSIs. Hook it into the platform MSI framework and
enjoy faults being reported in a new and exciting way.
Signed-off-by: Marc Zyngier
---
* From v3:
- Pass the device as a parameter to the MSI destructor
On 13/10/15 16:41, Will Deacon wrote:
> Hi Marc,
>
> On Thu, Oct 08, 2015 at 03:52:00PM +0100, Marc Zyngier wrote:
>> Despite being a platform device, the SMMUv3 is capable of signaling
>> interrupts using MSIs. Hook it into the platform MSI framework and
>> enjoy fau
Despite being a platform device, the SMMUv3 is capable of signaling
interrupts using MSIs. Hook it into the platform MSI framework and
enjoy faults being reported in a new and exciting way.
Signed-off-by: Marc Zyngier
---
* From v2:
- MSI indexes as an enum
- Fixed stupid 16bit writes
Despite being a platform device, the SMMUv3 is capable of signaling
interrupts using MSIs. Hook it into the platform MSI framework and
enjoy faults being reported in a new and exciting way.
Signed-off-by: Marc Zyngier
---
Now rebased on top of Will's iommu/devel branch, which leads to
a sli
Despite being a platform device, the SMMUv3 is capable of signaling
interrupts using MSIs. Hook it into the platform MSI framework and
enjoy faults being reported in a new and exciting way.
Signed-off-by: Marc Zyngier
---
drivers/iommu/arm-smmu-v3.c | 78
e
> need to rework that before v4.3.
>
> Marc, can I take it from your use of the binding that you are happy to
> provide your ack?
Definitely.
Acked-by: Marc Zyngier
M.
--
Jazz is not dead. It just smells funny...
___
i
On 27/07/15 10:46, Mark Rutland wrote:
> On Mon, Jul 27, 2015 at 09:02:46AM +0100, Marc Zyngier wrote:
>> Hi Mark,
>
> Hi,
>
>> On 23/07/15 17:52, Mark Rutland wrote:
>>> Currently msi-parent is used in a couple of drivers despite being fairly
>>>
On 23/07/15 17:52, Mark Rutland wrote:
> Currently msi-parent is used by a few bindings to describe the
> relationship between a PCI root complex and a single MSI controller, but
> this property does not have a generic binding document.
>
> Additionally, msi-parent is insufficient to describe more
Hi Mark,
On 23/07/15 17:52, Mark Rutland wrote:
> Currently msi-parent is used in a couple of drivers despite being fairly
> underspecified. This patch adds a generic binding for MSIs (including
> the existing msi-parent property) enabling the description of platform
> devices capable of using MSI
On Thu, 23 Jul 2015 19:26:11 +0100
David Daney wrote:
> On 07/23/2015 09:52 AM, Mark Rutland wrote:
> [...]
> > +MSI clients
> > +===
> > +
> > +MSI clients are devices which generate MSIs. For each MSI they wish to
> > +generate, the doorbell and payload may be configured, though sideban
outing at me while everything
was indeed working just fine.
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
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
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
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 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 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
101 - 139 of 139 matches
Mail list logo