On Tue, Sep 25, 2018 at 7:01 PM, Jordan Glover
wrote:
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, September 25, 2018 1:57 PM, Joerg Roedel wrote:
>
>> Lu,
>>
>> can you please have a look at this problem?
>>
>> On Wed, Sep 05, 2018 at 02:04:38PM +0200, Sedat Dilek wrote:
>>
>> > Hi Joerg,
>>
On Tue, Sep 25, 2018 at 10:09 PM Will Deacon wrote:
>
> On Tue, Sep 25, 2018 at 02:09:34PM +0200, Joerg Roedel wrote:
> > On Mon, Sep 10, 2018 at 11:55:47AM +0530, Vivek Gautam wrote:
> > > Vivek Gautam (4):
> > > firmware: qcom_scm-64: Add atomic version of qcom_scm_call
> > > firmware/qcom_s
Hi Robin,
On Wed, Sep 26, 2018 at 12:25 AM Robin Murphy wrote:
>
> Hi Vivek,
>
> On 2018-09-25 6:56 AM, Vivek Gautam wrote:
> > Hi Robin, Will,
> >
> > On Tue, Sep 18, 2018 at 8:41 AM Vivek Gautam
> > wrote:
> >>
> >> Hi Robin,
> >>
> >> On Fri, Sep 7, 2018 at 3:52 PM Vivek Gautam
> >> wrote:
Also cc maintainer and other reviewer. Thanks.
在 2018年09月26日 13:52, lijiang 写道:
> 在 2018年09月26日 03:10, Lendacky, Thomas 写道:
>> On 09/07/2018 03:18 AM, Lianbo Jiang wrote:
>>> When SME is enabled on AMD machine, we also need to support kdump. Because
>>> the memory is encrypted in the first kernel,
Christoph Hellwig writes:
> Looking at the code I think this commit is simply broken for
> architectures not using arch_setup_dma_ops, but instead setting up
> the dma ops through arch specific magic.
I arch_setup_dma_ops() called from of_dma_configure(), but
pci_dma_configure() doesn't call tha
Hi,
On 09/25/2018 06:32 PM, Jean-Philippe Brucker wrote:
On 25/09/2018 04:15, Lu Baolu wrote:
+ /* If an io_mm already exists, use it */
+ spin_lock(&iommu_sva_lock);
+ idr_for_each_entry(&iommu_pasid_idr, io_mm, i) {
This might be problematic for vt-d (and other possible arch's w
Hi Lianbo,
On 09/07/18 at 04:18pm, Lianbo Jiang wrote:
> When SME is enabled on AMD machine, the memory is encrypted in the first
> kernel. In this case, SME also needs to be enabled in kdump kernel, and
> we have to remap the old memory with the memory encryption mask.
This patch series looks go
Hi,
On 09/26/2018 01:55 AM, Jean-Philippe Brucker wrote:
On 19/09/2018 00:26, Tian, Kevin wrote:
If the core actually calls it, we can implement detach_dev :) The
problem is that the core never calls detach_dev when default_domain is
present (affects any IOMMU driver that relies on default_doma
From: Kuninori Morimoto
This patch updates license to use SPDX-License-Identifier
instead of verbose license text.
Signed-off-by: Kuninori Morimoto
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Simon Horman
---
Joerg
2 weeks past. resend patch
drivers/iommu/ipmmu-vmsa.c | 5 +
1 file
Hi Joerg,
On 09/25/2018 09:26 PM, Joerg Roedel wrote:
On Tue, Sep 25, 2018 at 11:15:40AM +0800, Lu Baolu wrote:
This might be problematic for vt-d (and other possible arch's which use
PASID other than SVA). When vt-d iommu works in scalable mode, a PASID
might be allocated for:
(1) SVA
(2) Dev
On Tue, 25 Sep 2018 15:16:47 +0200
Joerg Roedel wrote:
> On Sun, Sep 23, 2018 at 10:39:25AM +0800, Lu Baolu wrote:
> > > +int iommu_sva_init_device(struct device *dev, unsigned long
> > > features,
> > > +unsigned int min_pasid, unsigned int
> > > max_pasid) +{
> > > + int ret;
>
On Tue, 25 Sep 2018 15:58:41 +0100
Jean-Philippe Brucker wrote:
> Hi Jacob,
>
> Just two minor things below, that I noticed while using fault handlers
> for SVA. From my perspective the series is fine otherwise
>
> On 11/05/2018 21:54, Jacob Pan wrote:
> > +int iommu_unregister_device_fault_han
Looking at the code I think this commit is simply broken for
architectures not using arch_setup_dma_ops, but instead setting up
the dma ops through arch specific magic.
I'll revert the patch.
___
iommu mailing list
iommu@lists.linux-foundation.org
https:
On Sat, Sep 22, 2018 at 12:24:33PM -0700, Florian Fainelli wrote:
> >My thought would be that it would be ideal to fix in 4.19 since that's
> >where the breakage is, but having said that I don't have much insight
> >into how bad the breakage is for the affected systems.
>
>
> AFAIR, DMA corruptio
On Thu, 13 Sep 2018 15:15:29 +0200
Geert Uytterhoeven wrote:
> Currently the type-1 IOMMU instantiation depends on "ARM_SMMU ||
> ARM_SMMU_V3", while it applies to other ARM/ARM64 platforms with an
> IOMMU (e.g. Renesas VMSA-compatible IPMMUs).
>
> Instead of extending the list of IOMMU types on
On 09/07/2018 03:18 AM, Lianbo Jiang wrote:
> When SME is enabled on AMD machine, we also need to support kdump. Because
> the memory is encrypted in the first kernel, we will remap the old memory
> to the kdump kernel for dumping data, and SME is also enabled in the kdump
> kernel, otherwise the o
Hi Vivek,
On 2018-09-25 6:56 AM, Vivek Gautam wrote:
Hi Robin, Will,
On Tue, Sep 18, 2018 at 8:41 AM Vivek Gautam
wrote:
Hi Robin,
On Fri, Sep 7, 2018 at 3:52 PM Vivek Gautam wrote:
On Fri, Sep 7, 2018 at 3:22 PM Tomasz Figa wrote:
On Fri, Sep 7, 2018 at 6:38 PM Vivek Gautam wrote:
On 19/09/2018 00:26, Tian, Kevin wrote:
>> If the core actually calls it, we can implement detach_dev :) The
>> problem is that the core never calls detach_dev when default_domain is
>> present (affects any IOMMU driver that relies on default_domain,
>> including AMD), and even in case 4) the defau
‐‐‐ Original Message ‐‐‐
On Tuesday, September 25, 2018 1:57 PM, Joerg Roedel wrote:
> Lu,
>
> can you please have a look at this problem?
>
> On Wed, Sep 05, 2018 at 02:04:38PM +0200, Sedat Dilek wrote:
>
> > Hi Joerg,
> > "intel_ioomu=on" was working fine here on my ThinkPad T470 with
>
On Tue, Sep 25, 2018 at 02:09:34PM +0200, Joerg Roedel wrote:
> On Mon, Sep 10, 2018 at 11:55:47AM +0530, Vivek Gautam wrote:
> > Vivek Gautam (4):
> > firmware: qcom_scm-64: Add atomic version of qcom_scm_call
> > firmware/qcom_scm: Add atomic version of io read/write APIs
> > firmware/qcom_
Hi Joerg,
> -Original Message-
> From: Joerg Roedel
> Sent: Tuesday, September 25, 2018 7:02 PM
> To: Nath, Arindam
> Cc: iommu@lists.linux-foundation.org; Suthikulpanit, Suravee
>
> Subject: Re: [PATCH] iommu/amd: return devid as alias for ACPI HID devices
>
> Hi Arindam,
>
> On Tue,
Hi Jacob,
Just two minor things below, that I noticed while using fault handlers
for SVA. From my perspective the series is fine otherwise
On 11/05/2018 21:54, Jacob Pan wrote:
> +int iommu_unregister_device_fault_handler(struct device *dev)
> +{
> + struct iommu_param *param = dev->iommu_p
On 9/25/18 1:00 PM, Thierry Reding wrote:
> On Mon, Sep 24, 2018 at 09:39:43PM +0300, Dmitry Osipenko wrote:
>> On 9/24/18 1:13 PM, Thierry Reding wrote:
>>> On Mon, Sep 24, 2018 at 03:41:44AM +0300, Dmitry Osipenko wrote:
There is no need to match device with the DT node since it was already
On 9/25/18 1:09 PM, Thierry Reding wrote:
> On Mon, Sep 24, 2018 at 08:50:35PM +0300, Dmitry Osipenko wrote:
>> On 9/24/18 2:10 PM, Thierry Reding wrote:
>>> On Mon, Sep 24, 2018 at 03:41:52AM +0300, Dmitry Osipenko wrote:
GART is a simple IOMMU provider that has single address space. There is
On 9/25/18 1:04 PM, Thierry Reding wrote:
> On Mon, Sep 24, 2018 at 09:05:48PM +0300, Dmitry Osipenko wrote:
>> On 9/24/18 2:00 PM, Thierry Reding wrote:
>>> On Mon, Sep 24, 2018 at 03:41:51AM +0300, Dmitry Osipenko wrote:
There could be unlimited number of allocated domains, but only one doma
On 9/25/18 1:03 PM, Thierry Reding wrote:
> On Mon, Sep 24, 2018 at 09:57:10PM +0300, Dmitry Osipenko wrote:
>> On 9/24/18 1:52 PM, Thierry Reding wrote:
>>> On Mon, Sep 24, 2018 at 03:41:49AM +0300, Dmitry Osipenko wrote:
GART is a part of the Memory Controller driver that is always built-in,
On Tue, Sep 18, 2018 at 05:38:49PM +0300, Rami Rosen wrote:
> This patch fixes a typo in iommu.c.
>
> Signed-off-by: Rami Rosen
> ---
> drivers/iommu/iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
___
iommu mailing li
Hi Arindam,
On Tue, Sep 18, 2018 at 03:40:58PM +0530, Arindam Nath wrote:
> @@ -246,7 +246,13 @@ static u16 get_alias(struct device *dev)
>
> /* The callers make sure that get_device_id() does not fail here */
> devid = get_device_id(dev);
> +
> + /* For ACPI HID devices, we simp
On Tue, Sep 25, 2018 at 11:15:40AM +0800, Lu Baolu wrote:
> This might be problematic for vt-d (and other possible arch's which use
> PASID other than SVA). When vt-d iommu works in scalable mode, a PASID
> might be allocated for:
>
> (1) SVA
> (2) Device Assignable Interface (might be a mdev or d
On Sun, Sep 23, 2018 at 10:39:25AM +0800, Lu Baolu wrote:
> > +int iommu_sva_init_device(struct device *dev, unsigned long features,
> > + unsigned int min_pasid, unsigned int max_pasid)
> > +{
> > + int ret;
> > + struct iommu_sva_param *param;
> > + struct iommu_domain *dom
Hi Robin,
On Tue, Sep 25, 2018 at 11:48:17AM +0100, Robin Murphy wrote:
> Will has the cleaned-up version in his tree along with a couple of other
> SMMU fixes, which I assume he's planning to send you a pull for (he's off at
> yet another conference just now so I can't confirm offline).
Okay, le
On Wed, Sep 19, 2018 at 11:12:57AM +0100, Robin Murphy wrote:
> The external interface to get/set window attributes is already
> abstracted behind iommu_domain_{get,set}_attr(), so there's no real
> reason for the internal interface to be different. Since we only have
> one window-based driver anyw
On Tue, Sep 11, 2018 at 05:11:35PM -0700, Sohil Mehta wrote:
> Sohil Mehta (5):
> iommu/vt-d: Relocate struct/function declarations to its header files
> iommu/vt-d: Update register definitions to VT-d 3.0 specification
> iommu/vt-d: Enable base Intel IOMMU debugfs support
> iommu/vt-d: Add
On 10/09/18 07:25, Vivek Gautam wrote:
Qcom's implementation of arm,mmu-500 require to serialize all
TLB invalidations for context banks.
What does "serailize all TLB invalidations" actually mean, because it's
not entirely clear from context, and furthermore this patch appears to
behave subtl
On 9/24/18 4:22 PM, Dmitry Osipenko wrote:
> On 9/24/18 1:02 PM, Thierry Reding wrote:
>> On Mon, Sep 24, 2018 at 03:41:42AM +0300, Dmitry Osipenko wrote:
>>> The tegra20-mc device-tree binding has been changed, GART has been
>>> squashed into Memory Controller and now the clock property is mandato
On Tue, Sep 11, 2018 at 01:28:32PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in variable name
>
> Signed-off-by: Colin Ian King
> ---
> drivers/iommu/fsl_pamu_domain.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Applied, thanks.
___
On Mon, Sep 10, 2018 at 11:55:47AM +0530, Vivek Gautam wrote:
> Vivek Gautam (4):
> firmware: qcom_scm-64: Add atomic version of qcom_scm_call
> firmware/qcom_scm: Add atomic version of io read/write APIs
> firmware/qcom_scm: Add scm call to handle smmu errata
> iommu/arm-smmu: Add support
On Fri, Sep 07, 2018 at 04:18:04PM +0800, Lianbo Jiang wrote:
> In kdump kernel, it will copy the device table of IOMMU from the old device
> table, which is encrypted when SME is enabled in the first kernel. So we
> have to remap the old device table with the memory encryption mask.
>
> Signed-of
On Fri, Sep 07, 2018 at 01:42:15AM +, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto
>
> This patch updates license to use SPDX-License-Identifier
> instead of verbose license text.
>
> Signed-off-by: Kuninori Morimoto
> Reviewed-by: Geert Uytterhoeven
> Reviewed-by: Simon Horman
Lu,
can you please have a look at this problem?
On Wed, Sep 05, 2018 at 02:04:38PM +0200, Sedat Dilek wrote:
> Hi Joerg,
>
> "intel_ioomu=on" was working fine here on my ThinkPad T470 with
> debian/testing AMD64 with Linux v4.17.y and v4.18.y.
>
> With testing Linux v4.19-rc1 and v4.19-rc2 my m
On Sat, Sep 01, 2018 at 02:24:16PM +0800, Lu Baolu wrote:
> Pasid table memory allocation could return failure due to memory
> shortage. Limit the pasid table size to 1MiB because current 8MiB
> contiguous physical memory allocation can be hard to come by. W/o
> a PASID table, the device could cont
On Thu, Aug 30, 2018 at 07:28:32PM -0300, Ezequiel Garcia wrote:
> Printing verbosely via WARN macros and friends in interrupt handlers
> is strongly discouraged. Drop them and use proper ratelimited
> prints.
>
> Signed-off-by: Ezequiel Garcia
> ---
> drivers/iommu/rockchip-iommu.c | 10 ++-
Hi Joerg,
On 25/09/18 10:01, Joerg Roedel wrote:
Hey Robin,
On Thu, Aug 23, 2018 at 01:14:59PM +0100, Robin Murphy wrote:
Fixes: 2c3d273eabe8 ("iommu/io-pgtable-arm: Support lockless operation")
Signed-off-by: Robin Murphy
I can't find a newer version of this in my inbox, do you plan to sen
On 25/09/2018 04:15, Lu Baolu wrote:
>> + /* If an io_mm already exists, use it */
>> + spin_lock(&iommu_sva_lock);
>> + idr_for_each_entry(&iommu_pasid_idr, io_mm, i) {
>
> This might be problematic for vt-d (and other possible arch's which use
> PASID other than SVA). When vt-d iommu
On Mon, Sep 24, 2018 at 08:50:35PM +0300, Dmitry Osipenko wrote:
> On 9/24/18 2:10 PM, Thierry Reding wrote:
> > On Mon, Sep 24, 2018 at 03:41:52AM +0300, Dmitry Osipenko wrote:
> >> GART is a simple IOMMU provider that has single address space. There is
> >> no need to setup global clients list an
On Mon, Sep 24, 2018 at 09:05:48PM +0300, Dmitry Osipenko wrote:
> On 9/24/18 2:00 PM, Thierry Reding wrote:
> > On Mon, Sep 24, 2018 at 03:41:51AM +0300, Dmitry Osipenko wrote:
> >> There could be unlimited number of allocated domains, but only one domain
> >> can be active at a time. Hence device
On Mon, Sep 24, 2018 at 09:57:10PM +0300, Dmitry Osipenko wrote:
> On 9/24/18 1:52 PM, Thierry Reding wrote:
> > On Mon, Sep 24, 2018 at 03:41:49AM +0300, Dmitry Osipenko wrote:
> >> GART is a part of the Memory Controller driver that is always built-in,
> >> hence there is no benefit from the use
On Mon, Sep 24, 2018 at 09:22:59PM +0300, Dmitry Osipenko wrote:
> On 9/24/18 1:23 PM, Thierry Reding wrote:
> > On Mon, Sep 24, 2018 at 03:41:45AM +0300, Dmitry Osipenko wrote:
> >> The device-tree binding has been changed. There is no separate GART device
> >> anymore, it is squashed into the Mem
On Mon, Sep 24, 2018 at 09:39:43PM +0300, Dmitry Osipenko wrote:
> On 9/24/18 1:13 PM, Thierry Reding wrote:
> > On Mon, Sep 24, 2018 at 03:41:44AM +0300, Dmitry Osipenko wrote:
> >> There is no need to match device with the DT node since it was already
> >> matched, use of_device_get_match_data()
On Mon, Aug 27, 2018 at 12:56:24PM +0200, Heiko Stuebner wrote:
> In the iommu's shutdown handler we disable runtime-pm which could
> result in the irq-handler running unclocked and since commit
> 3fc7c5c0cff3 ("iommu/rockchip: Handle errors returned from PM framework")
> we warn about that fac
On Fri, Aug 24, 2018 at 02:28:49PM +, murph...@tcd.ie wrote:
> From: Tom Murphy
>
> ---
>
> This patch allows the IOMMU API path in the AMD driver to be called
> from an atomic context. This is useful for anyone building a driver
> which needs to call the IOMMU API while holding a spinlock.
Hey Robin,
On Thu, Aug 23, 2018 at 01:14:59PM +0100, Robin Murphy wrote:
> Fixes: 2c3d273eabe8 ("iommu/io-pgtable-arm: Support lockless operation")
> Signed-off-by: Robin Murphy
I can't find a newer version of this in my inbox, do you plan to send
one or has it been addressed differently?
Rega
On Wed, Sep 12, 2018 at 04:24:11PM +0100, Robin Murphy wrote:
> Robin Murphy (3):
> iommu: Add fast hook for getting DMA domains
> iommu/dma: Use fast DMA domain lookup
> arm64/dma-mapping: Mildly optimise non-coherent IOMMU ops
Applied, thanks Robin.
On Wed, Sep 05, 2018 at 09:57:36AM +0530, Ganapatrao Kulkarni wrote:
> drivers/iommu/iova.c | 22 +++---
> include/linux/iova.h | 1 +
> 2 files changed, 16 insertions(+), 7 deletions(-)
Applied, thanks.
___
iommu mailing list
iommu@lis
On Mon, Aug 27, 2018 at 08:56:50AM +0200, Geert Uytterhoeven wrote:
> If it is that bad, shouldn't this option be protected by some Kconfig
> trickery to avoid it being enabled in allmodconfig/allyesconfig builds?
It is fine to have it in allmodconfig/allyesconfig, I just don't want
any distro-ker
On Mon, Sep 10, 2018 at 07:19:14PM +0530, Nipun Gupta wrote:
> Nipun Gupta (7):
> Documentation: fsl-mc: add iommu-map device-tree binding for fsl-mc
> bus
> iommu/of: make of_pci_map_rid() available for other devices too
> iommu/of: support iommu configuration for fsl-mc devices
> iomm
56 matches
Mail list logo
