> On 10 Dec 2019, at 22:37, Bjorn Helgaas wrote:
>
> [+cc Joerg]
>
> On Tue, Dec 03, 2019 at 03:43:53PM +, James Sewart wrote:
>> pci_add_dma_alias can now be used to create a dma alias for a range of
>> devfns.
>>
>> Reviewed-by: Logan Gunthorpe
>> Signed-off-by: James Sewart
>> ---
The PLX PEX NTB forwards DMA transactions using Requester ID's that
don't exist as PCI devices. The devfn for a transaction is used as an
index into a lookup table storing the origin of a transaction on the
other side of the bridge.
This patch aliases all possible devfn's to the NTB device so
pci_add_dma_alias can now be used to create a dma alias for a range of
devfns.
Reviewed-by: Logan Gunthorpe
Signed-off-by: James Sewart
---
drivers/pci/pci.c| 22 +-
drivers/pci/quirks.c | 14 +++---
include/linux/pci.h | 2 +-
3 files changed, 25
The number of possible devfns is 256, add def and correct uses.
Reviewed-by: Logan Gunthorpe
Signed-off-by: James Sewart
---
drivers/pci/pci.c| 2 +-
drivers/pci/search.c | 2 +-
include/linux/pci.h | 2 ++
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci.c
pci_add_dma_alias can now be used to create a dma alias for a range of
devfns.
Signed-off-by: James Sewart
---
drivers/pci/pci.c| 23 ++-
drivers/pci/quirks.c | 14 +++---
include/linux/pci.h | 2 +-
3 files changed, 26 insertions(+), 13 deletions(-)
diff
The number of possible devfns is 256 so the size of the bitmap for
allocations should be U8_MAX+1.
Signed-off-by: James Sewart
---
drivers/pci/pci.c| 2 +-
drivers/pci/search.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index
The PLX PEX NTB forwards DMA transactions using Requester ID's that
don't exist as PCI devices. The devfn for a transaction is used as an
index into a lookup table storing the origin of a transaction on the
other side of the bridge.
This patch aliases all possible devfn's to the NTB device so
> On 29 Nov 2019, at 16:50, Logan Gunthorpe wrote:
>
>
>
> On 2019-11-29 5:49 a.m., James Sewart wrote:
>> pci_add_dma_alias can now be used to create a dma alias for a range of
>> devfns.
>>
>> Signed-off-by: James Sewart
>> ---
>> drivers/pci/pci.c| 23 ++-
>>
The PLX PEX NTB forwards DMA transactions using Requester ID's that
don't exist as PCI devices. The devfn for a transaction is used as an
index into a lookup table storing the origin of a transaction on the
other side of the bridge.
This patch aliases all possible devfn's to the NTB device so
pci_add_dma_alias can now be used to create a dma alias for a range of
devfns.
Signed-off-by: James Sewart
---
drivers/pci/pci.c| 23 ++-
drivers/pci/quirks.c | 14 +++---
include/linux/pci.h | 2 +-
3 files changed, 26 insertions(+), 13 deletions(-)
diff
The PLX PEX NTB forwards DMA transactions using Requester ID's that
don't exist as PCI devices. The devfn for a transaction is used as an
index into a lookup table storing the origin of a transaction on the
other side of the bridge.
This patch aliases all possible devfn's to the NTB device so
pci_add_dma_alias can now be used to create a dma alias for a range of
devfns.
Signed-off-by: James Sewart
---
drivers/pci/pci.c| 21 -
drivers/pci/quirks.c | 14 +++---
include/linux/pci.h | 2 +-
3 files changed, 24 insertions(+), 13 deletions(-)
diff --git
The PLX PEX NTB forwards DMA transactions using Requester ID's that
don't exist as PCI devices. The devfn for a transaction is used as an
index into a lookup table storing the origin of a transaction on the
other side of the bridge.
This patch aliases all possible devfn's to the NTB device so
pci_add_dma_alias_range can be used to create a dma alias for range of
devfns.
Reviewed-by: Logan Gunthorpe
Signed-off-by: James Sewart
---
drivers/pci/pci.c | 30 +++---
include/linux/pci.h | 1 +
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git
The PLX PEX NTB forwards DMA transactions using Requester ID's that
don't exist as PCI devices. The devfn for a transaction is used as an
index into a lookup table storing the origin of a transaction on the
other side of the bridge.
Add helper pci_add_dma_alias_range that can alias a range of
Any comments on this?
Cheers,
James.
> On 24 Oct 2019, at 13:52, James Sewart wrote:
>
> The PLX PEX NTB forwards DMA transactions using Requester ID's that don't
> exist as
> PCI devices. The devfn for a transaction is used as an index into a lookup
> table
> storing the origin of a
The PLX PEX NTB forwards DMA transactions using Requester ID's that don't exist
as
PCI devices. The devfn for a transaction is used as an index into a lookup table
storing the origin of a transaction on the other side of the bridge.
This patch aliases all possible devfn's to the NTB device so
Hey Lu,
> On 10 Apr 2019, at 06:22, Lu Baolu wrote:
>
> Hi James,
>
> On 4/6/19 2:02 AM, James Sewart wrote:
>> Hey Lu,
>> My bad, did some debugging on my end. The issue was swapping out
>> find_domain for iommu_get_domain_for_dev. It seems in some situations the
>> domain is not attached to
Hey Lu,
My bad, did some debugging on my end. The issue was swapping out
find_domain for iommu_get_domain_for_dev. It seems in some situations the
domain is not attached to the group but the device is expected to have the
domain still stored in its archdata.
I’ve attached the final patch with
Hey Lu,
I’ve attached a preliminary v3, if you could take a look and run some tests
that would be great.
Since v2 i’ve added your default domain type patches, the new device_group
handler, and incorporated Jacob’s feedback.
> On 28 Mar 2019, at 18:37, James Sewart wrote:
>
> Hey Lu,
>
>>
Hey Lu,
> On 26 Mar 2019, at 01:24, Lu Baolu wrote:
>
> Hi James,
>
> On 3/25/19 8:57 PM, James Sewart wrote:
Theres an issue that if we choose to alloc a new resv_region with type
IOMMU_RESV_DIRECT, we will need to refactor intel_iommu_put_resv_regions
to free this entry type
Hey Lu,
> On 25 Mar 2019, at 02:03, Lu Baolu wrote:
>
> Hi James,
>
> On 3/22/19 5:57 PM, James Sewart wrote:
>> Hey Lu,
>>> On 15 Mar 2019, at 02:19, Lu Baolu wrote:
>>>
>>> Hi James,
>>>
>>> On 3/14/19 7:58 PM, James Sewart wrote:
To support mapping ISA region via
Hey Jacob,
> On 14 Mar 2019, at 23:35, Jacob Pan wrote:
>
> On Thu, 14 Mar 2019 11:59:36 +
> James Sewart wrote:
>
>>
>> -domain = get_valid_domain_for_dev(dev);
>> +domain = find_domain(dev);
>> if (!domain)
>> return DMA_MAPPING_ERROR;
>>
>> @@ -3914,7
Hey Lu,
> On 20 Mar 2019, at 01:26, Lu Baolu wrote:
>
> Hi James,
>
> On 3/19/19 9:35 PM, James Sewart wrote:
>> Hey Lu,
>>> On 15 Mar 2019, at 03:13, Lu Baolu wrote:
>>>
>>> Hi James,
>>>
>>> On 3/14/19 7:56 PM, James Sewart wrote:
Patches 1 and 2 are the same as v1.
v1-v2:
Hey Lu,
> On 15 Mar 2019, at 02:19, Lu Baolu wrote:
>
> Hi James,
>
> On 3/14/19 7:58 PM, James Sewart wrote:
>> To support mapping ISA region via iommu_group_create_direct_mappings,
>> make sure its exposed by iommu_get_resv_regions. This allows
>> deduplication of reserved region mappings
>>
Hey Lu,
> On 15 Mar 2019, at 03:13, Lu Baolu wrote:
>
> Hi James,
>
> On 3/14/19 7:56 PM, James Sewart wrote:
>> Patches 1 and 2 are the same as v1.
>> v1-v2:
>> Refactored ISA direct mappings to be returned by iommu_get_resv_regions.
>> Integrated patch by Lu to defer turning on DMAR
Allowing IOMMU_DOMAIN_DMA type IOMMU domain to be allocated allows the
default_domain of an iommu_group to be set. This delegates device-domain
relationships to the generic IOMMU code.
Signed-off-by: James Sewart
---
drivers/iommu/intel-iommu.c | 99 +
1 file
The generic IOMMU code will allocate and attach a default domain to each
device that comes online. This patch removes the lazy domain allocation
and early reserved region mapping that is now redundant.
Signed-off-by: James Sewart
---
drivers/iommu/intel-iommu.c | 300
The rmrr devices require identity map of the rmrr regions before
enabling DMA remapping. Otherwise, there will be a window during
which DMA from/to the rmrr regions will be blocked. In order to
alleviate this, we move enabling DMA remapping after all rmrr
regions get mapped.
Signed-off-by: Lu
If a device requires an identity map then it is not safe to attach a
domain that can remap addresses. Warn the user if this occurs.
Signed-off-by: James Sewart
---
drivers/iommu/intel-iommu.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c
To support mapping ISA region via iommu_group_create_direct_mappings,
make sure its exposed by iommu_get_resv_regions. This allows
deduplication of reserved region mappings
Signed-off-by: James Sewart
---
drivers/iommu/intel-iommu.c | 42 +
1 file changed, 33
Used by iommu.c before creating identity mappings for reserved ranges to
ensure dma-ops won't ever remap these ranges
Signed-off-by: James Sewart
---
drivers/iommu/intel-iommu.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c
If an IOMMU driver requires to know which IOMMU a domain is associated
to initialise a domain then it will do so in device_attach, before which
it is not safe to call iommu_ops.
Signed-off-by: James Sewart
---
drivers/iommu/iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Patches 1 and 2 are the same as v1.
v1-v2:
Refactored ISA direct mappings to be returned by iommu_get_resv_regions.
Integrated patch by Lu to defer turning on DMAR until iommu.c has mapped
reserved regions.
Integrated patches by Lu to remove more unused code in cleanup.
Lu: I didn't
Hey Lu,
> On 8 Mar 2019, at 03:09, Lu Baolu wrote:
>
> Hi James,
>
> On 3/7/19 6:21 PM, James Sewart wrote:
>> Hey Lu,
>>> On 7 Mar 2019, at 06:31, Lu Baolu wrote:
>>>
>>> Hi James,
>>>
>>> On 3/7/19 2:08 AM, James Sewart wrote:
- /*
- * For each rmrr
-
Hey Lu,
> On 7 Mar 2019, at 06:31, Lu Baolu wrote:
>
> Hi James,
>
> On 3/7/19 2:08 AM, James Sewart wrote:
>> -/*
>> - * For each rmrr
>> - * for each dev attached to rmrr
>> - * do
>> - * locate drhd for dev, alloc domain
Hey,
> On 6 Mar 2019, at 07:00, Lu Baolu wrote:
>
> Hi,
>
> On 3/5/19 7:46 PM, James Sewart wrote:
>> Hey Lu,
>>> On 5 Mar 2019, at 06:59, Lu Baolu wrote:
>>>
>>> Hi,
>>>
>>> It's hard for me to understand why do we remove the rmrr related
>>> code in this patch.
>> The RMRR code removed
Hey Lu,
> On 5 Mar 2019, at 06:59, Lu Baolu wrote:
>
> Hi,
>
> It's hard for me to understand why do we remove the rmrr related
> code in this patch.
The RMRR code removed here requires the lazy allocation of domains to
exist, as it is run before iommu.c would assign IOMMU groups and attach
Hey Lu,
> On 5 Mar 2019, at 06:46, Lu Baolu wrote:
>
> Hi,
>
> On 3/4/19 11:46 PM, James Sewart wrote:
>> Allowing IOMMU_DOMAIN_DMA type IOMMU domain to be allocated allows the
>> default_domain of an iommu_group to be set. This delegates device-domain
>> relationships to the generic IOMMU
Hey Lu,
The motivation for this is buggy domain <-> IOMMU group relationship when
using find_or_alloc_domain. From what I have read it should be the case
that an IOMMU domain is shared by all devices in the same group, thus the
same mappings. This is because the IOMMU group is determined by
Allowing IOMMU_DOMAIN_DMA type IOMMU domain to be allocated allows the
default_domain of an iommu_group to be set. This delegates device-domain
relationships to the generic IOMMU code.
Signed-off-by: James Sewart
---
drivers/iommu/intel-iommu.c | 113 +++-
1 file
The generic IOMMU code will allocate and attach a dma ops domain to each
device that comes online, replacing any lazy allocated domain. Removes
RMRR application at iommu init time as we won't have a domain attached
to any device. iommu.c will do this after attaching a device using
If an IOMMU driver requires to know which IOMMU a domain is associated
to initialise a domain then it will do so in device_attach, before which
it is not safe to call iommu_ops.
Signed-off-by: James Sewart
---
drivers/iommu/iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Used by iommu.c before creating identity mappings for reserved ranges to
ensure dma-map-ops won't ever remap these addresses.
Signed-off-by: James Sewart
---
drivers/iommu/intel-iommu.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c
Hey,
This patchset moves IOMMU_DOMAIN_DMA iommu domain management to iommu.c.
This avoids the use of find_or_alloc_domain whose domain assignment is
inconsistent with the iommu grouping as determined by pci_device_group.
Patch 3 permits domain type IOMMU_DOMAIN_DMA to be allocated via the
Hey Jacob,
> On 7 Jan 2019, at 20:04, Jacob Pan wrote:
>
> On Wed, 5 Dec 2018 17:19:35 +
> James Sewart wrote:
>
>> Hey,
>>
>> There exists an issue in the logic used to determine domain
>> association with devices. Currently the driver uses
>> find_or_alloc_domain to either reuse an
Bump
> On 5 Dec 2018, at 17:19, James Sewart wrote:
>
> Hey,
>
> There exists an issue in the logic used to determine domain association
> with devices. Currently the driver uses find_or_alloc_domain to either
> reuse an existing domain or allocate a new one if one isn’t found. Domains
>
Hey,
There exists an issue in the logic used to determine domain association
with devices. Currently the driver uses find_or_alloc_domain to either
reuse an existing domain or allocate a new one if one isn’t found. Domains
should be shared between all members of an IOMMU group as this is the
tween A and B?
>>
>> I’m not sure we need to sync them. Domain A would be replaced
>> entirely for a certain device with domain B by attach_device. As we
>> saw above domain A would be freed if there are no more devices
>> attached to it. Domain B would be managed
//vfio.blogspot.com/2014/08/iommu-groups-inside-and-out.html
Thanks for the link, this explains how I expected the group domain
relationship to work.
>
>> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
>> boun...@lists.linux-foundation.org] On Behalf Of James Sewart via i
domain.
Cheers,
James.
>
> Need to go through the code to find out more.
>
> Best regards,
> Lu Baolu
>> Cheers,
>> James.
>>>
>>> I haven't spent time on details. So I cc'ed Jacob for corrections.
>>>
>>> Best regards,
>>>
needed and calling domain_free.
Cheers,
James.
>
> I haven't spent time on details. So I cc'ed Jacob for corrections.
>
> Best regards,
> Lu Baolu
>
>> Cheers,
>> James.
>> On Fri, Nov 2, 2018 at 2:43 AM Lu Baolu wrote:
>>>
>>> Hi,
>>>
Hey Lu,
Would you be able to go into more detail about the issues with
allowing IOMMU_DOMAIN_DMA to be allocated via domain_alloc?
Cheers,
James.
On Fri, Nov 2, 2018 at 2:43 AM Lu Baolu wrote:
>
> Hi,
>
> On 10/30/18 10:18 PM, James Sewart via iommu wrote:
> > Hey,
Hey,
I’ve been investigating the relationship between iommu groups and domains
on our systems and have a few question. Why does the intel iommu code not
allow allocating IOMMU_DOMAIN_DMA? Returning NULL when given this domain
type has the side effect that the default_domain for an iommu group
54 matches
Mail list logo
