To make sure iovad->cached32_node and iovad->cached64_node can exactly
control dma32 and dma64 area. It also help us to remove the parameter
pfn_32bit of init_iova_domain.
Signed-off-by: Zhen Lei
---
drivers/iommu/amd_iommu.c| 7 ++-
drivers/iommu/dma-iommu.c| 22 +--
Keep these four variables type consistent with the paramters of function
__alloc_and_insert_iova_range and the members of struct iova:
1. static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
unsigned long size, unsigned long limit_pfn,
2. struct iova {
unsig
Currently we always search free iova space for dma64 begin at the last
node of iovad rb-tree. In the worst case, there maybe too many nodes exist
at the tail, so that we should traverse many times for the first loop in
__alloc_and_insert_iova_range. As we traced, more than 10K times for the
case of
Reserve the first granule size memory(start at start_pfn) as boundary
iova, to make sure that iovad->cached32_node can not be NULL in future.
Meanwhile, changed the assignment of iovad->cached32_node from rb_next to
rb_prev of &free->node in function __cached_rbnode_delete_update.
Signed-off-by: Z
Below judgement can only be satisfied at the last time, which produced 2N
judgements(suppose N times failed, 0 or 1 time successed) in vain.
if ((pfn >= iova->pfn_lo) && (pfn <= iova->pfn_hi)) {
return iova;
}
Signed-off-by: Zhen Lei
---
drivers/iommu/iova.c | 9 +++--
1 file change
I'm not sure whether the compiler can optimize it, but move it out will
be better. At least, it does not require lock protection.
Signed-off-by: Zhen Lei
---
drivers/iommu/iova.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/iova.c b/d
64 bits devices is very common now. But currently we only defined a
cached32_node
to optimize the allocation performance of dma32, and I saw some dma64 drivers
chose
to allocate iova from dma32 space first, maybe becuase of current dma64
performance
problem or some other reasons.
For example:(i
For case 2 and 3, adjust cached32_node to the new place, case 1 keep no
change.
For example:
case1: (the right part was allocated)
|--|
|<-free>|<--new_iova-->|
|
|
cached32_node
case2: (all was allocated)
|---
On Tue, 21 Mar 2017 19:37:56 +
Jean-Philippe Brucker wrote:
> > For invalidation, I've following info in in pseudo code.
> > struct iommu_svm_tlb_invalidate_info
> > {
> >__u32 inv_type;
> > #define IOTLB_INV (1 << 0)
> > #define EXTENDED_IOTLB_INV (1 << 1)
On 08/03/17 15:26, Sinan Kaya wrote:
> On 2/27/2017 2:54 PM, Jean-Philippe Brucker wrote:
>> +ats_enabled = !arm_smmu_enable_ats(master);
>> +
>
> You should make ats_supported field in IORT table part of the decision
> process for when to enable ATS.
>
Agreed. I will also draft a proposal f
On 21/03/17 07:04, Liu, Yi L wrote:
> Hi Jean,
>
> I'm working on virtual SVM, and have some comments on the VFIO channel
> definition.
Thanks a lot for the comments, this is quite interesting to me. I just
have some concerns about portability so I'm proposing a way to be slightly
more generic be
On Tue, Mar 21, 2017 at 05:46:29PM +, Robin Murphy wrote:
> On 21/03/17 17:21, Will Deacon wrote:
> > On Tue, Mar 21, 2017 at 04:45:27PM +0100, Joerg Roedel wrote:
> >> On Fri, Mar 10, 2017 at 08:49:36PM +, Will Deacon wrote:
> >>> @@ -1014,8 +1027,8 @@ struct iommu_group *iommu_group_get_f
On 21/03/17 17:21, Will Deacon wrote:
> On Tue, Mar 21, 2017 at 04:45:27PM +0100, Joerg Roedel wrote:
>> On Fri, Mar 10, 2017 at 08:49:36PM +, Will Deacon wrote:
>>> @@ -1014,8 +1027,8 @@ struct iommu_group *iommu_group_get_for_dev(struct
>>> device *dev)
>>> * IOMMU driver.
>>> */
>
On 21/03/17 17:08, Will Deacon wrote:
> Hi Robin,
>
> On Thu, Mar 16, 2017 at 06:19:48PM +, Robin Murphy wrote:
>> On 16/03/17 16:24, Nate Watterson wrote:
>>> On 2017-03-10 15:49, Will Deacon wrote:
In preparation for allowing the default domain type to be overridden,
this patch add
On Tue, Mar 21, 2017 at 04:45:27PM +0100, Joerg Roedel wrote:
> On Fri, Mar 10, 2017 at 08:49:36PM +, Will Deacon wrote:
> > @@ -1014,8 +1027,8 @@ struct iommu_group *iommu_group_get_for_dev(struct
> > device *dev)
> > * IOMMU driver.
> > */
> > if (!group->default_domain) {
> >
Hi Robin,
On Thu, Mar 16, 2017 at 06:19:48PM +, Robin Murphy wrote:
> On 16/03/17 16:24, Nate Watterson wrote:
> > On 2017-03-10 15:49, Will Deacon wrote:
> >> In preparation for allowing the default domain type to be overridden,
> >> this patch adds support for IOMMU_DOMAIN_IDENTITY domains t
On Tue, Mar 21, 2017 at 04:42:41PM +, Will Deacon wrote:
> Hi Joerg,
>
> On Tue, Mar 21, 2017 at 04:46:24PM +0100, Joerg Roedel wrote:
> > On Fri, Mar 10, 2017 at 08:49:31PM +, Will Deacon wrote:
> > > Will Deacon (5):
> > > iommu/arm-smmu: Restrict domain attributes to UNMANAGED domains
Hi Joerg,
On Tue, Mar 21, 2017 at 04:46:24PM +0100, Joerg Roedel wrote:
> On Fri, Mar 10, 2017 at 08:49:31PM +, Will Deacon wrote:
> > Will Deacon (5):
> > iommu/arm-smmu: Restrict domain attributes to UNMANAGED domains
> > iommu/arm-smmu: Install bypass S2CRs for IOMMU_DOMAIN_IDENTITY dom
> -Original Message-
> From: 'j...@8bytes.org' [mailto:j...@8bytes.org]
> Sent: Tuesday, March 21, 2017 12:26 PM
> To: Deucher, Alexander
> Cc: Bridgman, John; Alex Deucher; Daniel Drake; Chris Chiu; amd-
> g...@lists.freedesktop.org; Nath, Arindam; iommu@lists.linux-
> foundation.org; Suth
On Tue, Mar 21, 2017 at 04:17:40PM +, Deucher, Alexander wrote:
> > -Original Message-
> > From: 'j...@8bytes.org' [mailto:j...@8bytes.org]
> > Sent: Tuesday, March 21, 2017 12:11 PM
> > To: Deucher, Alexander
> > Cc: Alex Deucher; Daniel Drake; Chris Chiu; amd-...@lists.freedesktop.org
On 21/03/2017 15:23, Liviu Dudau wrote:
> On Tue, Mar 21, 2017 at 02:01:57PM +0100, Mason wrote:
>
>> My PCIe controller is b/d/f 0/0/0.
>> It ignores all PCI addresses that do not fall within the range
>> defined in BAR0 of b/d/f 0/0/0.
>>
>> BAR0 has a configurable width of 2^(23+i) bytes, i < 8
> -Original Message-
> From: 'j...@8bytes.org' [mailto:j...@8bytes.org]
> Sent: Tuesday, March 21, 2017 12:11 PM
> To: Deucher, Alexander
> Cc: Alex Deucher; Daniel Drake; Chris Chiu; amd-...@lists.freedesktop.org;
> Nath, Arindam; iommu@lists.linux-foundation.org; Suthikulpanit, Suravee;
>
>-Original Message-
>From: 'j...@8bytes.org' [mailto:j...@8bytes.org]
>Sent: Tuesday, March 21, 2017 9:41 PM
>To: Deucher, Alexander
>Cc: Alex Deucher; Daniel Drake; Chris Chiu; amd-...@lists.freedesktop.org;
>Nath, Arindam; iommu@lists.linux-foundation.org; Suthikulpanit, Suravee;
>Linux U
On Tue, Mar 21, 2017 at 04:01:53PM +, Deucher, Alexander wrote:
> It seems to only affect Stoney systems, but not others (Carrizo,
> Bristol, etc.). Maybe we could just disable it on Stoney until we
> root cause it.
Completion-wait loop timeouts indicate something is seriously wrong. How
can
> -Original Message-
> From: j...@8bytes.org [mailto:j...@8bytes.org]
> Sent: Tuesday, March 21, 2017 11:57 AM
> To: Alex Deucher
> Cc: Daniel Drake; Deucher, Alexander; Chris Chiu; amd-
> g...@lists.freedesktop.org; Nath, Arindam; iommu@lists.linux-
> foundation.org; Suthikulpanit, Suravee
On Fri, Mar 17, 2017 at 11:53:09AM -0400, Alex Deucher wrote:
> On Fri, Mar 17, 2017 at 8:15 AM, Daniel Drake wrote:
> > Hi,
> >
> > On Mon, Mar 13, 2017 at 2:01 PM, Deucher, Alexander
> > wrote:
> >> > We are unable to boot Acer Aspire E5-553G (AMD FX-9800P RADEON R7) nor
> >> > Acer Aspire E5-5
On Tue, Mar 07, 2017 at 06:43:32PM +0100, Geert Uytterhoeven wrote:
> Add support for allocating physically contiguous DMA buffers on arm64
> systems with an IOMMU. This can be useful when two or more devices
> with different memory requirements are involved in buffer sharing.
>
> Note that as th
On Fri, Mar 10, 2017 at 08:49:31PM +, Will Deacon wrote:
> Will Deacon (5):
> iommu/arm-smmu: Restrict domain attributes to UNMANAGED domains
> iommu/arm-smmu: Install bypass S2CRs for IOMMU_DOMAIN_IDENTITY domains
> iommu/arm-smmu-v3: Make arm_smmu_install_ste_for_dev return void
> iom
Hi Will,
On Fri, Mar 10, 2017 at 08:49:36PM +, Will Deacon wrote:
> @@ -1014,8 +1027,8 @@ struct iommu_group *iommu_group_get_for_dev(struct
> device *dev)
>* IOMMU driver.
>*/
> if (!group->default_domain) {
> - group->default_domain = __iommu_domain_alloc(d
On Tue, Mar 21, 2017 at 02:01:57PM +0100, Mason wrote:
> On 21/03/2017 13:31, Liviu Dudau wrote:
>
> > On Tue, Mar 21, 2017 at 11:15:16AM +0100, Mason wrote:
> >>
> >> On 17/03/2017 17:11, Mason wrote:
> >>
> >>> + * QUIRK #5
> >>> + * Only transfers within the BAR are forwarded to the host.
> >>>
On Fri, Feb 24, 2017 at 12:13:37PM +0100, Marek Szyprowski wrote:
> This patch consolidates almost the same code used in iova_insert_rbtree()
> and __alloc_and_insert_iova_range() functions. While touching this code,
> replace BUG() with WARN_ON(1) to avoid taking down the whole system in
> case of
On 21/03/2017 13:31, Liviu Dudau wrote:
> On Tue, Mar 21, 2017 at 11:15:16AM +0100, Mason wrote:
>>
>> On 17/03/2017 17:11, Mason wrote:
>>
>>> + * QUIRK #5
>>> + * Only transfers within the BAR are forwarded to the host.
>>> + * By default, the DMA framework expects that
>>> + * PCI address 0x800
On Tue, Mar 21, 2017 at 11:15:16AM +0100, Mason wrote:
> [ Adding iommu ML ]
>
> On 17/03/2017 17:11, Mason wrote:
>
> > + * QUIRK #5
> > + * Only transfers within the BAR are forwarded to the host.
> > + * By default, the DMA framework expects that
> > + * PCI address 0x8000_ -> CPU address
On 21/03/2017 13:43, Mason wrote:
> On 21/03/2017 12:36, Robin Murphy wrote:
>
>> On 21/03/17 10:15, Mason wrote:
>>
>>> I suppose one may consider the above limitation ("Only transfers
>>> within the BAR are forwarded to the host") as some form of weird
>>> IOMMU? (There is, in fact, some remappin
On 21/03/2017 12:36, Robin Murphy wrote:
> On 21/03/17 10:15, Mason wrote:
>
>> I suppose one may consider the above limitation ("Only transfers
>> within the BAR are forwarded to the host") as some form of weird
>> IOMMU? (There is, in fact, some remapping logic in the controller
>> setup which I
On 21/03/17 10:15, Mason wrote:
> [ Adding iommu ML ]
>
> On 17/03/2017 17:11, Mason wrote:
>
>> + * QUIRK #5
>> + * Only transfers within the BAR are forwarded to the host.
>> + * By default, the DMA framework expects that
>> + * PCI address 0x8000_ -> CPU address 0x8000_
>> + * which is
[ Adding iommu ML ]
On 17/03/2017 17:11, Mason wrote:
> + * QUIRK #5
> + * Only transfers within the BAR are forwarded to the host.
> + * By default, the DMA framework expects that
> + * PCI address 0x8000_ -> CPU address 0x8000_
> + * which is where DRAM0 is mapped.
I have an additional
Hi Jean,
I'm working on virtual SVM, and have some comments on the VFIO channel
definition.
> -Original Message-
> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> boun...@lists.linux-foundation.org] On Behalf Of Jean-Philippe Brucker
> Sent: Tuesday, February 28, 2017 3:55
38 matches
Mail list logo
