On 11/26/2021 8:22 PM, Thomas Gleixner wrote:
There is no reason to walk the MSI descriptors to retrieve the interrupt
number for a device. Use msi_get_virq() instead.
Signed-off-by: Thomas Gleixner
Cc: Sinan Kaya
Cc:dmaeng...@vger.kernel.org
Acked-by: Sinan Kaya
On 3/20/2019 1:36 PM, Jean-Philippe Brucker wrote:
err = pci_for_each_dma_alias(to_pci_dev(dev),
iort_pci_iommu_init, &info);
+
+ if (!err && !iort_pci_rc_supports_ats(node))
+ dev->iommu_fwspec->flag
On 3/20/2019 1:36 PM, Jean-Philippe Brucker wrote:
pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ATS);
+ if (!pos)
+ return -ENOSYS;
+
You don't need this. pci_enable_ats() validates this via.
if (!dev->ats_cap)
return -EINVAL;
___
On 2/11/2019 2:15 PM, Raj, Ashok wrote:
It seems rather odd we have to check for ATS version.
I always assumed unspecified bits (Reserved) must be 0. We only check
this if ATS is enabled, and this particular bit wasn't given away for another
feature.
Is it really required to check for ATS versi
On 2/8/2019 8:02 PM, sathyanarayanan kuppuswamy wrote:
This means that you should probably have some kind of version check
here.
There is no version field in ATS v1.0 spec. Also, If I follow the
history log in PCI spec, I think ATS if first added at v1.2. Please
correct me if I am wrong.
v1
On 2/7/2019 5:16 PM, sathyanarayanan kuppuswamy wrote:
If I remember this right, aligned request is only supported on ATS v1.1
but not supported on v1.0.
Its added in v1.1.
This means that you should probably have some kind of version check
here.
_
On 2/7/2019 1:41 PM, sathyanarayanan.kuppusw...@linux.intel.com wrote:
+ * As per PCI spec, If page aligned request bit is set, it indicates
+ * the untranslated address is always aligned to a 4096 byte boundary.
+ */
+int pci_ats_page_aligned(struct pci_dev *pdev)
+{
+ u16 cap;
+
+
On 9/26/2018 1:20 PM, Sinan Kaya wrote:
This patch actually broke the integrated endpoints like you were mentioning.
It was fixed by a follow up patch from nvidia guys.
https://github.com/torvalds/linux/commit/9d27e39d309c93025ae6aa97236af15bef2a5f1f#diff-a7f0acd715e991df5dfb450d2b9abebc
On 9/26/2018 12:22 PM, Raj, Ashok wrote:
pcie_capability_read_dword(dev, PCI_EXP_DEVCAP2, &cap);
+ if (!(cap & PCI_EXP_DEVCAP2_E2ETLP))
+ return;
Forgot to notice this.. I'm not sure if the same enforcement is
required for devices that are RCIEP. The spec isn't clear about ca
On 8/1/2018 12:29 AM, Christoph Hellwig wrote:
I asked this question to Tony Luck before. If I remember right,
his answer was:
CPU guarantees outstanding writes to be flushed when a register write
instruction is executed and an additional barrier instruction is not
needed.
That would be great.
+iommu folks.
On 5/19/2018 12:52 PM, Sinan Kaya wrote:
> A PCIe endpoint carries the process address space identifier (PASID) in
> the TLP prefix as part of the memory read/write transaction. The address
> information in the TLP is relevant only for a given PASID context.
>
> A tr
ch point there isn't any device attached anymore.
>
> Signed-off-by: Jean-Philippe Brucker
Nothing specific about this patch but just a general observation. Last time I
looked at the code, it seemed to require both ATS and PRI support from a given
hardware.
I think you can assume th
+Bjorn,
On 5/3/2018 9:59 AM, Joerg Roedel wrote:
> On Thu, May 03, 2018 at 09:46:34AM -0400, Sinan Kaya wrote:
>> I also like the idea in general.
>> Minor nit..
>>
>> Shouldn't this be an iommu parameter rather than a PCI kernel command line
>> paramete
arameter rather than a PCI kernel command line
parameter?
We now have an iommu.passthrough argument that prevents page translation.
Doesn't this fit into the same category especially when it is the IOMMU drivers
that
call ATS functions for enablement not the PCI drivers.
--
Sinan Kaya
Qualcomm
XIST or
> similar. So in next version a driver can call bind(devX, mmY) multiple
> times, but the first unbind() removes the bond.
If we are going to allow multiple binds, then the last unbind should
remove the bond rather than the first one via reference counting.
--
Sinan Kaya
Qualcomm Da
return pasid when you find an io_mm that is already bound. Something like
*pasid = io_mm->pasid should do the work here when bond is true.
> + return 0;
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies,
On 4/11/2018 8:03 AM, Robin Murphy wrote:
> On 10/04/18 21:59, Sinan Kaya wrote:
>> Code is expecing to observe the same number of buffers returned from
>> dma_map_sg() function compared to sg_alloc_table_from_pages(). This
>> doesn't hold true universally especia
with yield and maybe an informational message
with might help if wait exceeds some time.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation C
of_dma_deconfigure(dev);
> + acpi_dma_deconfigure(dev);
> +}
Isn't this one or the other one but not both?
Something like:
if (dev->of_node)
of_dma_deconfigure(dev);
else
acpi_dma_deconfigure(dev);
should work.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as
On 2/12/2018 1:33 PM, Jean-Philippe Brucker wrote:
> +static struct workqueue_struct *iommu_fault_queue;
Is there anyway we can make this fault queue per struct device?
Since this is common code, I think it needs some care.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affili
> + spin_unlock(&iommu_partial_faults_lock);
> +
> + return IOMMU_PAGE_RESP_HANDLED;
> + }
> +
> + group = kzalloc(sizeof(*group), GFP_KERNEL);
> + if (!group)
> + return -ENOMEM;
Release the requests in iommu_partial_faults here.
Is there any reason why you can't call iommu->release()
here directly? Why do you need the release local variable?
> + mmdrop(mm);
> +}
> +
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies,
n-memory data structures left by a previous kernel and infer the
> setup from that.
Let me know if you have something to test. We have a test case with the
crash.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc.
do care about the adapter coming up properly otherwise how would
you collect the dumps from the system?
I was expecting to come through the network interface and download it from
the target.
That's why, I was suggesting FLR/PM reset etc. when we know that we are
booting a kdump kernel.
--
Sin
PA is configured so
> that transactions are terminated when SMMUEN=0.
How about the points that Baoquan highlighted in his email regarding the
solution from AMD and X86?
I have not read the entire thread but, is this just a matter of following
what Bjorn recommended or there is more to it?
On 3/1/2018 2:05 PM, Bjorn Helgaas wrote:
> [+cc Joerg, David, iommu list]
>
> On Thu, Mar 01, 2018 at 12:44:26PM -0500, Sinan Kaya wrote:
>> Hi,
>>
>> We are seeing IOMMU faults when booting the kdump kernel on ARM64.
>>
>> [7.220162] arm-smmu-v3
iommu_sva_unbind_device(device->dev, pasid);
> + mutex_unlock(&group->mutex);
> +
> + return 0;
> +}
I think we should handle the errors returned by iommu_sva_unbind_device() here
or at least print a warning if we want to still continue unbinding.
--
AULT;
> +
> + if (params.flags & ~VFIO_IOMMU_BIND_PID)
> + return -EINVAL;
> +
> + /*
> + * We can't simply unbind a foreign process by PASID, because the
> + * process might have died and the PASID might have been reallocated to
> + * ano
>device_info->max_pasid_bits seems to contain per device limitations.
Would you be willing to extend the API so that the requester can impose some
limit
on the PASID value that is getting allocated.
Sinan
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Tec
On 1/4/2018 11:28 AM, Gary R Hook wrote:
> On 01/04/2018 06:25 AM, Sinan Kaya wrote:
>> On 12/19/2017 12:37 AM, Sinan Kaya wrote:
>>> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
>>> where a PCI device is present. This restricts the device d
On 12/19/2017 12:37 AM, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Getting ready to remove pci_get_bus_and_slot() funct
number as 0 for the AMD IOMMU driver.
Signed-off-by: Sinan Kaya
---
drivers/iommu/amd_iommu.c | 3 ++-
drivers/iommu/amd_iommu_init.c | 9 +
drivers/iommu/amd_iommu_v2.c | 3 ++-
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu
number as 0 for the AMD IOMMU driver.
Signed-off-by: Sinan Kaya
---
drivers/iommu/amd_iommu.c | 3 ++-
drivers/iommu/amd_iommu_init.c | 9 +
drivers/iommu/amd_iommu_v2.c | 3 ++-
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu
number as 0 for the AMD IOMMU driver.
Signed-off-by: Sinan Kaya
---
drivers/iommu/amd_iommu.c | 3 ++-
drivers/iommu/amd_iommu_init.c | 9 +
drivers/iommu/amd_iommu_v2.c | 3 ++-
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu
, use the actual domain number from
the device.
Signed-off-by: Sinan Kaya
---
drivers/iommu/amd_iommu.c | 3 ++-
drivers/iommu/amd_iommu_init.c | 10 ++
drivers/iommu/amd_iommu_v2.c | 3 ++-
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/amd_iomm
lock(&iommu_process_lock);
> + put_pid(pid);
> +
> + if (context)
> + return err;
I think you should make the section above a independent function and return
here when the
context is found.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate o
alloc maybe?
> + context->process= process;
> + context->domain = domain;
> + refcount_set(&context->ref, 1);
> +
> + spin_lock(&iommu_process_lock);
> + err = domain->ops->process_attach(domain, dev, process, true)
S-2011-03-31.pdf),
PASID should be enabled only if all switches between the root port and
a device support TLP prefix.
I'm only seeing a call to pci_enable_pasid() in this patch but I don't
see anybody checking for TLP prefix support on the hierarchy.
This could potentially be an
iommu_init_device
amd_iommu_free_device
amd_iommu_bind_pasid
amd_iommu_set_invalid_ppr_cb
amd_iommu_unbind_pasid
amd_iommu_device_info
Sinan
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Hi Alex,
Thank you very much for the detailed explanation.
On 4/4/2017 3:39 PM, Alex Williamson wrote:
> On Tue, 4 Apr 2017 14:47:58 -0400
> Sinan Kaya wrote:
>
[cut]
>> The requirement is to have an
>> 1. ACS capability with PCI_ACS_SV if p2p is not supported
>
S_SV only.
So, if I summarize this correctly;
The requirement is to have an
1. ACS capability with PCI_ACS_SV if p2p is not supported
2. ACS capability with PCI_ACS_SV|PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF if p2p
is supported.
Did I get this right?
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc
On 3/6/2017 6:04 AM, Joerg Roedel wrote:
> On Wed, Feb 22, 2017 at 05:39:44PM -0600, Bjorn Helgaas wrote:
>> [+cc Joerg, iommu list]
>>
>> On Wed, Feb 22, 2017 at 03:44:53PM -0500, Sinan Kaya wrote:
>>> On 2/22/2017 1:44 PM, Bjorn Helgaas wrote:
>>>> T
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.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qu
_depth
> + * invalidations to the same device.
> + */
> + arm_smmu_cmdq_issue_cmd(smmu, &sync_cmd);
> +
It is possible to observe ATS invalidation timeout up to 90 seconds according
to PCIe
spec. How does the current code deal with this?
--
Sinan Kaya
Qualcomm Da
Hi Robin,
On 2/23/2017 6:40 AM, Robin Murphy wrote:
> On 22/02/17 23:39, Bjorn Helgaas wrote:
>> [+cc Joerg, iommu list]
>>
>> On Wed, Feb 22, 2017 at 03:44:53PM -0500, Sinan Kaya wrote:
>>> On 2/22/2017 1:44 PM, Bjorn Helgaas wrote:
>>>> There is no
Hi Alex,
On 2/15/2017 4:43 PM, Sinan Kaya wrote:
> On 2/15/2017 2:36 PM, Alex Williamson wrote:
>> On Tue, 14 Feb 2017 22:53:35 -0500
>> ok...@codeaurora.org wrote:
>>
>>> On 2017-02-14 18:51, Alex Williamson wrote:
>>>> On Tue, 14 Feb 2017 16:25:22 -0500
On 2/15/2017 2:36 PM, Alex Williamson wrote:
> On Tue, 14 Feb 2017 22:53:35 -0500
> ok...@codeaurora.org wrote:
>
>> On 2017-02-14 18:51, Alex Williamson wrote:
>>> On Tue, 14 Feb 2017 16:25:22 -0500
>>> Sinan Kaya wrote:
>>>
>>>> The ACS
The ACS requirement has been obscured in the current code and is only
known by certain individuals who happen to read the code. Print out a
warning with ACS path failure when ACS requirement is not met.
Signed-off-by: Sinan Kaya
---
drivers/iommu/iommu.c | 3 +++
1 file changed, 3 insertions
x27;t support peer-to-peer and each root port is a root complex
with unique segment numbers.
It is not possible for one root port to pass traffic to the other root
port. All PCIe transactions are terminated inside the root port.
Signed-off-by: Sinan Kaya
---
drivers/pci/quirks.c
On 2/14/2017 7:36 AM, Will Deacon wrote:
> On Mon, Feb 13, 2017 at 08:54:04PM -0500, Sinan Kaya wrote:
>> On 2/13/2017 8:46 PM, Alex Williamson wrote:
>>>> My first goal is to support virtual function passthrough for device's that
>>>> are directly
>>
a good idea, sometimes the
> kernel does need to be smarter than the user to protect them from
> themselves. Any easy bypass also lets hardware vendors ignore the
> issue longer. Thanks,
Bjorn, any inputs?
>
> Alex
>
> [1] https://lkml.org/lkml/2013/5/30/513
>
--
Sinan
Hi Alex,
Thanks for your response. Other comments inline.
On 2/13/2017 6:06 PM, Alex Williamson wrote:
> On Mon, 13 Feb 2017 17:24:40 -0500
> Sinan Kaya wrote:
>
>> Hi,
>> I am getting ready to submit a quirk patch. Before I go ahead and submit
>> it for review
allback to generic_device_group() function in arm_smmu_device_group().
I'm just looking for a more permanent solution rather than relying on quirks
for chips
A, B, C and D.
Please let me know the preferred path.
Sinan
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Te
e,
> fix is already queued, so it is all good.
>
> What about USB stalls ?
>
> Thanks !
> Lorenzo
>
I'll get a hold of Nate and debug this. We were waiting for you to send us
debug code.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
On 1/30/2017 11:51 AM, Lorenzo Pieralisi wrote:
> On Mon, Jan 30, 2017 at 10:46:39AM -0500, Sinan Kaya wrote:
>> On 1/30/2017 9:54 AM, Nate Watterson wrote:
>>> On 2017-01-30 09:38, Will Deacon wrote:
>>>> On Mon, Jan 30, 2017 at 09:33:50AM -0500, Sinan Kaya wrote:
&g
On 1/30/2017 9:54 AM, Nate Watterson wrote:
> On 2017-01-30 09:38, Will Deacon wrote:
>> On Mon, Jan 30, 2017 at 09:33:50AM -0500, Sinan Kaya wrote:
>>> On 1/30/2017 9:23 AM, Nate Watterson wrote:
>>> > On 2017-01-30 08:59, Sinan Kaya wrote:
>>> >
On 1/30/2017 9:23 AM, Nate Watterson wrote:
> On 2017-01-30 08:59, Sinan Kaya wrote:
>> On 1/30/2017 7:22 AM, Robin Murphy wrote:
>>> On 29/01/17 17:53, Sinan Kaya wrote:
>>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>>>>> [+hanjun, tomasz, sin
On 1/30/2017 7:22 AM, Robin Murphy wrote:
> On 29/01/17 17:53, Sinan Kaya wrote:
>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>>> [+hanjun, tomasz, sinan]
>>>
>>> It is quite a key patchset, I would be glad if they can test on their
>>> respective
-4)
[ 264.421270] nvme nvme0: Removing after probe failure status: -5
/sys/bus/pci/slots/4 #
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundatio
0;
> - size = dev->coherent_dma_mask + 1;
> + size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
> } else {
what's happening here?
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Te
60 matches
Mail list logo
