On Mon, 12 Feb 2018 18:33:22 +
Jean-Philippe Brucker wrote:
> Some systems allow devices to handle IOMMU translation faults in the
> core mm. For example systems supporting the PCI PRI extension or Arm
> SMMU stall model. Infrastructure for reporting such recoverable page
> faults was recentl
On Wed, Feb 14, 2018 at 1:17 PM, Vivek Gautam
wrote:
> Hi Tomasz,
>
> On Wed, Feb 14, 2018 at 8:31 AM, Tomasz Figa wrote:
>> On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark wrote:
>>> On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa wrote:
On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark wrote:
> O
Hi Tomasz,
On Wed, Feb 14, 2018 at 8:31 AM, Tomasz Figa wrote:
> On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark wrote:
>> On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa wrote:
>>> On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark wrote:
On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa wrote:
> Hi Vi
On Tue, Feb 13, 2018 at 7:25 PM, Vivek Gautam
wrote:
>>> +static int arm_smmu_init_clks(struct arm_smmu_device *smmu)
>>> +{
>>> + int i;
>>> + int num = smmu->num_clks;
>>> + const struct arm_smmu_match_data *data;
>>> +
>>> + if (num < 1)
>>> + return 0;
>>>
Hi Jordan,
On Wed, Feb 14, 2018 at 1:42 AM, Jordan Crouse wrote:
> On Tue, Feb 13, 2018 at 06:10:38PM +0900, Tomasz Figa wrote:
>> Hi Vivek,
>>
>> Thanks for the patch. Please see my comments inline.
>>
>> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
>> wrote:
>> > While handling the concerned i
On Wed, Feb 14, 2018 at 11:13 AM, Rob Clark wrote:
> On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa wrote:
>> On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark wrote:
>>> On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa wrote:
Hi Vivek,
Thanks for the patch. Please see my comments inline.
>>>
On Tue, Feb 13, 2018 at 8:59 PM, Tomasz Figa wrote:
> On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark wrote:
>> On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa wrote:
>>> Hi Vivek,
>>>
>>> Thanks for the patch. Please see my comments inline.
>>>
>>> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
>>> wrot
On Wed, Feb 14, 2018 at 3:03 AM, Rob Clark wrote:
> On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa wrote:
>> Hi Vivek,
>>
>> Thanks for the patch. Please see my comments inline.
>>
>> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
>> wrote:
>>> While handling the concerned iommu, there should not be
On 02/11/2018 11:27 PM, Ingo Molnar wrote:
>
> * Randy Dunlap wrote:
>
>> From: Randy Dunlap
>>
>> Currently #includes for no obvious
>> reason. It looks like it's only a convenience, so remove kmemleak.h
>> from slab.h and add to any users of kmemleak_*
>> that don't already #include it.
>>
> From: Jean-Philippe Brucker
> Sent: Tuesday, February 13, 2018 8:40 PM
>
>
> [...]
> >> +
> >> +/**
> >> + * iommu_sva_device_init() - Initialize Shared Virtual Addressing for a
> >> device
> >> + * @dev: the device
> >> + * @features: bitmask of features that need to be initialized
> >> + * @m
> From: Jean-Philippe Brucker
> Sent: Tuesday, February 13, 2018 8:57 PM
>
> On 13/02/18 07:54, Tian, Kevin wrote:
> >> From: Jean-Philippe Brucker
> >> Sent: Tuesday, February 13, 2018 2:33 AM
> >>
> >> Add bind() and unbind() operations to the IOMMU API. Device drivers
> can
> >> use them to sha
On Tue, 13 Feb 2018 13:40:02 -0800
"Raj, Ashok" wrote:
> Hi Joerg,
>
> On Tue, Feb 13, 2018 at 03:03:03PM +0100, Joerg Roedel wrote:
> > On Fri, Feb 02, 2018 at 04:49:56PM -0800, Sohil Mehta wrote:
> > > This series aims to add debugfs support for Intel IOMMU. It
> > > exposes IOMMU registers,
Hi Joerg,
On Tue, Feb 13, 2018 at 03:03:03PM +0100, Joerg Roedel wrote:
> On Fri, Feb 02, 2018 at 04:49:56PM -0800, Sohil Mehta wrote:
> > This series aims to add debugfs support for Intel IOMMU. It exposes IOMMU
> > registers, internal context and dumps individual table entries to help debug
> >
On 02/13/2018 02:09 AM, Michael Ellerman wrote:
> Randy Dunlap writes:
>
>> On 02/12/2018 04:28 AM, Michael Ellerman wrote:
>>> Randy Dunlap writes:
>>>
From: Randy Dunlap
Currently #includes for no obvious
reason. It looks like it's only a convenience, so remove kmemleak.
On 2/13/2018 11:00 AM, Joerg Roedel wrote:
On Tue, Feb 13, 2018 at 10:47:55AM -0500, Hook, Gary wrote:
dev_err(&iommu->dev->dev, "ILLEGAL...
I think its more something like iommu->iommu->dev.
Without actually running a driver and getting some debug info, I'll just
say that my ex
On Mon, Feb 05, 2018 at 11:29:19PM +0530, Vivek Gautam wrote:
> Unmap returns a size_t all throughout the IOMMU framework.
> Make io-pgtable match this convention.
> Moreover, there isn't a need to have a signed int return type
> as we return 0 in case of failures.
>
> Signed-off-by: Vivek Gautam
On Mon, Feb 05, 2018 at 05:45:53AM -0500, Suravee Suthikulpanit wrote:
> Currently, iommu_unmap, iommu_unmap_fast and iommu_map_sg return
> size_t. However, some of the return values are error codes (< 0),
> which can be misinterpreted as large size. Therefore, returning size 0
> instead to signif
On Tue, Feb 13, 2018 at 4:10 AM, Tomasz Figa wrote:
> Hi Vivek,
>
> Thanks for the patch. Please see my comments inline.
>
> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
> wrote:
>> While handling the concerned iommu, there should not be a
>> need to power control the drm devices from iommu inter
On Tue, 2018-02-13 at 17:35 +0100, Joerg Roedel wrote:
> On Mon, Feb 12, 2018 at 04:48:23PM +, Dmitry Safonov wrote:
> > dmar_fault() reports/handles/cleans DMAR faults in a cycle one-by-
> > one.
> > The nuisance is that it's set as a irq handler and runs with
> > disabled
> > interrupts - whi
> Does this fix your warning?
>
> diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
> index 62f541f968f6..07074820a167 100644
> --- a/drivers/macintosh/macio_asic.c
> +++ b/drivers/macintosh/macio_asic.c
> @@ -375,6 +375,7 @@ static struct macio_dev * macio_add_one_devic
Hi Dmitry,
On Mon, Feb 12, 2018 at 04:48:19PM +, Dmitry Safonov wrote:
> Dmitry Safonov (6):
> iommu/intel: Add __init for dmar_register_bus_notifier()
> iommu/intel: Clean/document fault status flags
> iommu/intel: Introduce clear_primary_faults() helper
> iommu/intel: Handle DMAR fau
On Tue, Feb 13, 2018 at 06:10:38PM +0900, Tomasz Figa wrote:
> Hi Vivek,
>
> Thanks for the patch. Please see my comments inline.
>
> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
> wrote:
> > While handling the concerned iommu, there should not be a
> > need to power control the drm devices from
On Mon, Feb 12, 2018 at 04:48:23PM +, Dmitry Safonov wrote:
> dmar_fault() reports/handles/cleans DMAR faults in a cycle one-by-one.
> The nuisance is that it's set as a irq handler and runs with disabled
> interrupts - which works OK if you have only a couple of DMAR faults,
> but becomes a pr
On Tue, Feb 13, 2018 at 10:47:55AM -0500, Hook, Gary wrote:
>
> dev_err(&iommu->dev->dev, "ILLEGAL...
I think its more something like iommu->iommu->dev.
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxf
On 2/13/2018 8:22 AM, Joerg Roedel wrote:
On Tue, Jan 30, 2018 at 07:04:27PM -0600, Gary R Hook wrote:
+ dev_err(dev, "ILLEGAL_DEV_TABLE_ENTRY device=%02x:%02x.%x "
+ "address=0x%016llx flags=0x%04x]\n",
+ PCI_BUS_NUM(devid), PCI_SLOT(dev
Hi,
On Tue, Feb 13, 2018 at 3:51 PM, Christoph Hellwig wrote:
> Does this fix your warning?
>
> diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
> index 62f541f968f6..07074820a167 100644
> --- a/drivers/macintosh/macio_asic.c
> +++ b/drivers/macintosh/macio_asic.c
> @@
On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
deviates from the standard implementation and this breaks PCIe MSI
functionality when SMMU is enabled.
The HiSilicon erratum 161010801 describes this limitation of certain
HiSilicon platforms to support the SMMU mappings for MSI
Modified iommu_dma_get_resv_regions() to include GICv3 ITS
region on ACPI based ARM platfiorms which may require HW MSI
reservations.
Signed-off-by: Shameer Kolothum
Reviewed-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git
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 helper function that retrieves ITS address regions - the ms
Does this fix your warning?
diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
index 62f541f968f6..07074820a167 100644
--- a/drivers/macintosh/macio_asic.c
+++ b/drivers/macintosh/macio_asic.c
@@ -375,6 +375,7 @@ static struct macio_dev * macio_add_one_device(struct
maci
On Fri, Feb 02, 2018 at 04:49:56PM -0800, Sohil Mehta wrote:
> This series aims to add debugfs support for Intel IOMMU. It exposes IOMMU
> registers, internal context and dumps individual table entries to help debug
> Intel IOMMUs.
>
> The first patch does the ground work for the following patches
On Tue, Feb 13, 2018 at 9:57 PM, Robin Murphy wrote:
> On 13/02/18 08:24, Tomasz Figa wrote:
>>
>> Hi Vivek,
>>
>> Thanks for the patch. Please see my comments inline.
>>
>> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
>> wrote:
>>>
>>> From: Sricharan R
>>>
>>> The smmu device probe/remove and
On Fri, Jan 26, 2018 at 03:11:28PM +0800, Yong Wu wrote:
> ---
> drivers/iommu/mtk_iommu_v1.c | 54
> +---
> 1 file changed, 21 insertions(+), 33 deletions(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.
On 13/02/18 12:54, Tomasz Figa wrote:
On Tue, Feb 13, 2018 at 9:00 PM, Robin Murphy wrote:
On 13/02/18 07:44, Tomasz Figa wrote:
Hi Vivek,
On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
wrote:
The device link allows the pm framework to tie the supplier and
consumer. So, whenever the consume
On Wed, Jan 24, 2018 at 02:22:09PM +, Robin Murphy wrote:
> Since iommu_group_get_for_dev() already tries iommu_group_get() and will
> not call ops->device_group if the group is already non-NULL, the check
> in get_device_iommu_group() is always redundant and it reduces to a
> duplicate of the
Hi Suravee,
thanks for working on this.
On Wed, Jan 31, 2018 at 12:01:14AM -0500, Suravee Suthikulpanit wrote:
> +static void amd_iommu_iotlb_range_add(struct iommu_domain *domain,
> + unsigned long iova, size_t size)
> +{
> + struct amd_iommu_flush_entries *
Hi Baoquan,
On Fri, Jan 26, 2018 at 04:06:22PM +0800, Baoquan He wrote:
> Saw Huawei's bug report about kdump kernel hang when intel_iommu=off
> is set. I met the similar problem in amd system, only set amd_iommu=off
> in kdump kernel, it means amd_iommu is on in 1st kernel.
>
> I am reading doc
On Tue, Jan 30, 2018 at 07:04:27PM -0600, Gary R Hook wrote:
> + dev_err(dev, "ILLEGAL_DEV_TABLE_ENTRY device=%02x:%02x.%x "
> + "address=0x%016llx flags=0x%04x]\n",
> + PCI_BUS_NUM(devid), PCI_SLOT(devid), PCI_FUNC(devid),
> +
On Sun, Jan 28, 2018 at 02:22:19PM -0600, Scott Wood wrote:
> search_dev_data() acquires a non-raw lock, which can't be done
> from atomic context on PREEMPT_RT. There is no need to look at
> dev_data because guest_mode should never be set if use_vapic is
> not set.
>
> Signed-off-by: Scott Wood
On Sun, Jan 21, 2018 at 03:28:54AM -0600, Scott Wood wrote:
> Several functions in this driver are called from atomic context,
> and thus raw locks must be used in order to be safe on PREEMPT_RT.
>
> This includes paths that must wait for command completion, which is
> a potential PREEMPT_RT laten
Hi Scott,
On Sun, Jan 21, 2018 at 03:28:53AM -0600, Scott Wood wrote:
> The amd_iommu_rlookup_table[] check is not needed because
> irq_lookup_table[devid] should never be non-NULL if
> amd_iommu_rlookup_table[devid] is NULL.
Your reasoning is correct, but I'd like the patch make the code more
ro
On 13/02/18 08:24, Tomasz Figa wrote:
Hi Vivek,
Thanks for the patch. Please see my comments inline.
On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
wrote:
From: Sricharan R
The smmu device probe/remove and add/remove master device callbacks
gets called when the smmu is not linked to its maste
Hi,
On 13/02/18 01:46, Xu Zaibo wrote:
> Hi,
>
> On 2018/2/13 2:33, Jean-Philippe Brucker wrote:
>> The SMMU provides a Stall model for handling page faults in platform
>> devices. It is similar to PCI PRI, but doesn't require devices to have
>> their own translation cache. Instead, faulting tran
On 13/02/18 08:11, Tian, Kevin wrote:
>> From: Jean-Philippe Brucker
>> Sent: Tuesday, February 13, 2018 2:33 AM
>>
>> When an mm exits, devices that were bound to it must stop performing
>> DMA
>> on its PASID. Let device drivers register a callback to be notified on mm
>> exit. Add the callback t
On Tue, Feb 13, 2018 at 9:00 PM, Robin Murphy wrote:
> On 13/02/18 07:44, Tomasz Figa wrote:
>>
>> Hi Vivek,
>>
>> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
>> wrote:
>>>
>>> The device link allows the pm framework to tie the supplier and
>>> consumer. So, whenever the consumer is powered-on t
On 13/02/18 07:54, Tian, Kevin wrote:
>> From: Jean-Philippe Brucker
>> Sent: Tuesday, February 13, 2018 2:33 AM
>>
>> Add bind() and unbind() operations to the IOMMU API. Device drivers can
>> use them to share process page tables with their devices. bind_group()
>> is provided for VFIO's convenie
Hi Kevin,
Thanks for taking a look!
On 13/02/18 07:31, Tian, Kevin wrote:
>> From: Jean-Philippe Brucker
>> Sent: Tuesday, February 13, 2018 2:33 AM
>>
>> Shared Virtual Addressing (SVA) provides a way for device drivers to bind
>> process address spaces to devices. This requires the IOMMU to sup
On 13/02/18 07:44, Tomasz Figa wrote:
Hi Vivek,
On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
wrote:
The device link allows the pm framework to tie the supplier and
consumer. So, whenever the consumer is powered-on the supplier
is powered-on first.
There are however cases in which the consumer
Hi Tomasz,
Please find my response inline below.
On Tue, Feb 13, 2018 at 1:33 PM, Tomasz Figa wrote:
> Hi Vivek,
>
> Thanks for the patch. Please see some comments inline.
>
> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
> wrote:
>> From: Sricharan R
>>
>> The smmu needs to be functional only
Hi Tomasz,
On Tue, Feb 13, 2018 at 2:01 PM, Tomasz Figa wrote:
> Hi Vivek,
>
> Thanks for the patch. Please see my comments inline.
Thanks for reviewing the patch series.
>
> On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
> wrote:
>> From: Sricharan R
>>
>> Finally add the device link between
Randy Dunlap writes:
> On 02/12/2018 04:28 AM, Michael Ellerman wrote:
>> Randy Dunlap writes:
>>
>>> From: Randy Dunlap
>>>
>>> Currently #includes for no obvious
>>> reason. It looks like it's only a convenience, so remove kmemleak.h
>>> from slab.h and add to any users of kmemleak_*
>>>
Hi Will,
> -Original Message-
> From: Will Deacon [mailto:will.dea...@arm.com]
> Sent: Monday, January 29, 2018 4:21 PM
> To: Shameerali Kolothum Thodi
> Cc: lorenzo.pieral...@arm.com; robin.mur...@arm.com;
> marc.zyng...@arm.com; j...@8bytes.org; John Garry
> ; xuwei (O) ; Guohanjun
> (H
Hi Vivek,
Thanks for the patch. Please see my comments inline.
On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
wrote:
> While handling the concerned iommu, there should not be a
> need to power control the drm devices from iommu interface.
> If these drm devices need to be powered around this time,
Hi Vivek,
Thanks for the patch. Please see my comments inline.
On Fri, Feb 9, 2018 at 7:57 PM, Vivek Gautam
wrote:
> qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
> clock and power requirements. This smmu core is used with
> multiple masters on msm8996, viz. mdss, video, etc.
> Add
Hi Vivek,
Thanks for the patch. Please see my comments inline.
On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
wrote:
> From: Sricharan R
>
> Finally add the device link between the master device and
> smmu, so that the smmu gets runtime enabled/disabled only when the
> master needs it. This is do
Hi Vivek,
Thanks for the patch. Please see my comments inline.
On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
wrote:
> From: Sricharan R
>
> The smmu device probe/remove and add/remove master device callbacks
> gets called when the smmu is not linked to its master, that is without
> the context o
> From: Jean-Philippe Brucker
> Sent: Tuesday, February 13, 2018 2:33 AM
>
> When an mm exits, devices that were bound to it must stop performing
> DMA
> on its PASID. Let device drivers register a callback to be notified on mm
> exit. Add the callback to the iommu_param structure attached to stru
Hi Vivek,
Thanks for the patch. Please see some comments inline.
On Wed, Feb 7, 2018 at 7:31 PM, Vivek Gautam
wrote:
> From: Sricharan R
>
> The smmu needs to be functional only when the respective
> master's using it are active. The device_link feature
> helps to track such functional dependen
58 matches
Mail list logo
