On 2016/12/5 20:26, Lorenzo Pieralisi wrote:
> The introduction of acpi_dma_configure() allows to configure DMA
> and related IOMMU for any device that is DMA capable. To achieve
> that goal it ensures DMA masks are set-up to sane default values
> before proceeding with IOMMU and DMA ops configurat
Hi Joerg,
On Mon, Dec 05, 2016 at 11:18:56PM +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 5, 2016 at 1:26 PM, Lorenzo Pieralisi
> wrote:
> > The introduction of acpi_dma_configure() allows to configure DMA
> > and related IOMMU for any device that is DMA capable. To achieve
> > that goal it ensu
On Mon, Dec 05, 2016 at 12:26:19PM +, Lorenzo Pieralisi wrote:
> The introduction of acpi_dma_configure() allows to configure DMA
> and related IOMMU for any device that is DMA capable. To achieve
> that goal it ensures DMA masks are set-up to sane default values
> before proceeding with IOMMU
Hi Lorenzo,
On Tue, Dec 06, 2016 at 09:37:10AM +, Lorenzo Pieralisi wrote:
> I can apply Rafael and Hanjun's tags and resend a v2 to you if you
> prefer, it would be great if you could apply this patch to your arm/smmu
> branch for v4.10 as per description above, please let me know.
Yes, plea
The introduction of acpi_dma_configure() allows to configure DMA
and related IOMMU for any device that is DMA capable. To achieve
that goal it ensures DMA masks are set-up to sane default values
before proceeding with IOMMU and DMA ops configuration.
On x86/ia64 systems, through acpi_bind_one(), a
On Tue, Dec 06, 2016 at 02:24:48PM +0100, Joerg Roedel wrote:
> Hi Lorenzo,
>
> On Tue, Dec 06, 2016 at 09:37:10AM +, Lorenzo Pieralisi wrote:
> > I can apply Rafael and Hanjun's tags and resend a v2 to you if you
> > prefer, it would be great if you could apply this patch to your arm/smmu
> >
On Tue, Dec 06, 2016 at 02:20:11PM +, Lorenzo Pieralisi wrote:
> drivers/acpi/arm64/iort.c | 22 ++
> drivers/acpi/scan.c | 14 +-
> include/linux/acpi_iort.h | 2 ++
> 3 files changed, 25 insertions(+), 13 deletions(-)
Applied, thanks.
_
On Mon, Dec 05, 2016 at 08:09:07PM +0800, Xunlei Pang wrote:
> drivers/iommu/intel-iommu.c | 19 +++
> 1 file changed, 19 insertions(+)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundati
Hi Jacob,
On Thu, Dec 01, 2016 at 01:50:26PM -0800, Jacob Pan wrote:
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 27596e6..f112aa9 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -5173,6 +5173,29 @@ static void intel_iommu_rem
On 15/11/16 13:09, Eric Auger wrote:
> IOMMU_RESV_NOMAP is used to tag reserved IOVAs that are not
> supposed to be IOMMU mapped. IOMMU_RESV_MSI tags IOVAs
> corresponding to MSIs that need to be IOMMU mapped.
>
> IOMMU_RESV_MASK allows to check if the IOVA is reserved.
>
> Signed-off-by: Eric Au
On 15/11/16 13:09, Eric Auger wrote:
> We want to extend the callbacks used for dm regions and
> use them for reserved regions. Reserved regions can be
> - directly mapped regions
> - regions that cannot be iommu mapped (PCI host bridge windows, ...)
> - MSI regions (because they belong to another
On 15/11/16 13:09, Eric Auger wrote:
> Introduce a new helper serving the purpose to allocate a reserved
> region. This will be used in iommu driver implementing reserved
> region callbacks.
>
> Signed-off-by: Eric Auger
> ---
> drivers/iommu/iommu.c | 16
> include/linux/iommu
On Fri, Dec 02, 2016 at 08:25:09PM +0530, Sricharan R wrote:
> Currently the driver sets all the device transactions privileges
> to UNPRIVILEGED, but there are cases where the iommu masters wants
> to isolate privileged supervisor and unprivileged user.
> So don't override the privileged setting t
On Tue, 6 Dec 2016 17:31:11 +0100
Joerg Roedel wrote:
> Hi Jacob,
>
> On Thu, Dec 01, 2016 at 01:50:26PM -0800, Jacob Pan wrote:
> > diff --git a/drivers/iommu/intel-iommu.c
> > b/drivers/iommu/intel-iommu.c index 27596e6..f112aa9 100644
> > --- a/drivers/iommu/intel-iommu.c
> > +++ b/drivers/io
On 15/11/16 13:09, Eric Auger wrote:
> As we introduced IOMMU_RESV_NOMAP and IOMMU_RESV_MSI regions,
> let's prevent those new regions from being mapped.
>
> Signed-off-by: Eric Auger
> ---
> drivers/iommu/iommu.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/iommu/iommu.c
On 15/11/16 13:09, Eric Auger wrote:
> Introduce iommu_get_group_resv_regions whose role consists in
> enumerating all devices from the group and collecting their
> reserved regions. It checks duplicates.
>
> Signed-off-by: Eric Auger
>
> ---
>
> - we do not move list elements from device to gr
Different encodings are used to represent supported PASID bits
and number of PASID table entries.
The current code assigns ecap_pss directly to extended context
table entry PTS which is wrong and could result in writing
non-zero bits to the reserved fields. IOMMU fault reason
11 will be reported wh
On 15/11/16 13:09, Eric Auger wrote:
> The get() populates the list with the PCI host bridge windows
> and the MSI IOVA range.
>
> At the moment an arbitray MSI IOVA window is set at 0x800
> of size 1MB. This will allow to report those info in iommu-group
> sysfs?
>
> Signed-off-by: Eric Auge
On 04/12/16 07:48, Sricharan wrote:
> Hi Robin,
>
>> Hi Sricharan,
>>
>> On 02/12/16 14:55, Sricharan R wrote:
>>> This series is a resend of the V5 that Mitch sent sometime back [2]
>>> All the patches are the same and i have just rebased. Not sure why this
>>> finally did not make it last time.
> -Original Message-
> From: Xunlei Pang [mailto:xlp...@redhat.com]
> Sent: Monday, December 05, 2016 6:09 AM
> To: Joerg Roedel; David Woodhouse
> Cc: iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; Xunlei
> Pang; Myron Stowe; Joseph Szczypek; Don Brace; Baoquan He; Dave Yo
On Thu, Aug 18, 2016 at 9:05 AM, Will Deacon wrote:
> Enabling stalling faults can result in hardware deadlock on poorly
> designed systems, particularly those with a PCI root complex upstream of
> the SMMU.
>
> Although it's not really Linux's job to save hardware integrators from
> their own mis
On Tue, Dec 06, 2016 at 06:30:21PM -0500, Rob Clark wrote:
> On Thu, Aug 18, 2016 at 9:05 AM, Will Deacon wrote:
> > Enabling stalling faults can result in hardware deadlock on poorly
> > designed systems, particularly those with a PCI root complex upstream of
> > the SMMU.
> >
> > Although it's n
22 matches
Mail list logo
