Re: [PATCH] iommu/amd: flush IOTLB for specific domains only

Hi Arindam, You CC'd me on this - does this mean that it is a fix for the issue described in the thread "amd-iommu: can't boot with amdgpu, AMD-Vi: Completion-Wait loop timed out" ? Thanks Daniel On Mon, Mar 27, 2017 at 12:17 AM, wrote: > From: Arindam Nath

Re: amd-iommu: can't boot with amdgpu, AMD-Vi: Completion-Wait loop timed out

Hi Joerg, Thanks for looking into this. We confirm that this workaround avoids the iommu log spam and that amdgpu appears to be working fine with it. Daniel On Wed, Mar 22, 2017 at 5:22 AM, j...@8bytes.org wrote: > On Tue, Mar 21, 2017 at 04:30:55PM +, Deucher, Alexander

Re: amd-iommu: can't boot with amdgpu, AMD-Vi: Completion-Wait loop timed out

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-523 with standard configurations because during boot > > the screen is flooded with the following error message

amd-iommu: can't boot with amdgpu, AMD-Vi: Completion-Wait loop timed out

Hi, We are unable to boot Acer Aspire E5-553G (AMD FX-9800P RADEON R7) nor Acer Aspire E5-523 with standard configurations because during boot the screen is flooded with the following error message over and over: AMD-Vi: Completion-Wait loop timed out We have left the system for quite a while

DMAR table missing, Intel IOMMU not available

Hi, We're working with a number of platforms based on Intel Apollo Lake and there are some clues suggesting that the IR-PCI-MSI irqchip functionality would be able to get us out of a tricky situation described at: ath9k hardware corrupts MSI Message Data, raises wrong interrupt

Re: [PATCH] iommu/amd: flush IOTLB for specific domains only

On Wed, Apr 5, 2017 at 9:01 AM, Nath, Arindam <arindam.n...@amd.com> wrote: > > >-Original Message- > >From: Daniel Drake [mailto:dr...@endlessm.com] > >Sent: Thursday, March 30, 2017 7:15 PM > >To: Nath, Arindam > >Cc: j...@8bytes.org; Deuche

Re: [PATCH] iommu/amd: flush IOTLB for specific domains only (v3)

Hi, On Tue, May 30, 2017 at 3:38 PM, Nath, Arindam wrote: >>-Original Message- >>From: Joerg Roedel [mailto:j...@8bytes.org] >>Sent: Monday, May 29, 2017 8:09 PM >>To: Nath, Arindam ; Lendacky, Thomas >> >>Cc:

Re: [PATCH] iommu/vt-d: consider real PCI device when checking if mapping is needed

On Wed, Feb 12, 2020 at 12:03 AM Derrick, Jonathan wrote: > On Tue, 2020-02-11 at 17:13 +0800, Daniel Drake wrote: > > The PCI devices handled by intel-iommu may have a DMA requester on > > another bus, such as VMD subdevices needing to use the VMD endpoint. > > > >

[PATCH v3] iommu/vt-d: consider real PCI device when checking if mapping is needed

A device when checking if a mapping is needed, while also considering the subdevice DMA mask. The IDENTITY case will then directly fall back on dma_direct_map_page(). Reported-by: Daniel Drake Fixes: b0140c69637e ("iommu/vt-d: Use pci_real_dma_dev() for mapping") Signed-off-by: Jon Derr

[PATCH v4] iommu/vt-d: consider real PCI device when checking if mapping is needed

A device when checking if a mapping is needed. The IDENTITY case will then directly fall back on dma_direct_map_page(). The subdevice DMA mask is still considered in order to handle any situations where (e.g.) the subdevice only supports 32-bit DMA with the real DMA requester having a 64-bit DMA mask. Rep

[PATCH] iommu/vt-d: consider real PCI device when checking if mapping is needed

this by using the real DMA device when checking if a mapping is needed. The above case will then directly fall back on dma_direct_map_page(). Fixes: 2b0140c69637 ("iommu/vt-d: Use pci_real_dma_dev() for mapping") Signed-off-by: Daniel Drake --- Notes: This problem was detected with a non-

Re: [PATCH] iommu/intel-iommu: set as DUMMY_DEVICE_DOMAIN_INFO if no IOMMU

On Sat, Feb 8, 2020 at 2:30 PM Lu Baolu wrote: > > The devices under segment 1 are fake devices produced by > > intel-nvme-remap mentioned here https://lkml.org/lkml/2020/2/5/139 > > Has this series been accepted? Sadly not - we didn't find any consensus on the right approach, and further

[PATCH] iommu/dmar: ignore devices with out-of-spec domain number

ed-off-by: Daniel Drake --- Notes: This problem was detected with a non-upstream patch "PCI: Add Intel remapped NVMe device support" (https://marc.info/?l=linux-ide=156015271021615=2) This patch creates PCI devices in the same way as VMD, and hence I belie

[PATCH v2] iommu/vt-d: consider real PCI device when checking if mapping is needed

A device when checking if a mapping is needed, while also considering the subdevice DMA mask. The IDENTITY case will then directly fall back on dma_direct_map_page(). Reported-by: Daniel Drake Fixes: b0140c69637e ("iommu/vt-d: Use pci_real_dma_dev() for mapping") Signed-off-by: Daniel Drake ---

Re: [PATCH v4] iommu/vt-d: consider real PCI device when checking if mapping is needed

On Wed, Feb 19, 2020 at 11:40 AM Lu Baolu wrote: > With respect, this is problematical. The parent and all subdevices share > a single translation entry. The DMA mask should be consistent. > > Otherwise, for example, subdevice A has 64-bit DMA capability and uses > an identity domain for DMA

Re: [PATCH v4] iommu/vt-d: consider real PCI device when checking if mapping is needed

> On Wed, Feb 19, 2020 at 11:40 AM Lu Baolu wrote: > > With respect, this is problematical. The parent and all subdevices share > > a single translation entry. The DMA mask should be consistent. > > > > Otherwise, for example, subdevice A has 64-bit DMA capability and uses > > an identity domain

Re: [PATCH v2 00/33] iommu: Move iommu_group setup to IOMMU core code

Hi Joerg, > Hi, > > here is the second version of this patch-set. The first version with > some more introductory text can be found here: > > https://lore.kernel.org/lkml/20200407183742.4344-1-j...@8bytes.org/ Thanks for the continued improvements in this area! I may have spotted a

Re: [PATCH 1/1] iommu/vt-d: use DMA domain for real DMA devices and subdevices

Hi Jon, Thanks for picking this up. Apologies for my absence here - I wasn't able to work on this recently, but I'm back again now. On Fri, Apr 10, 2020 at 3:32 AM Jon Derrick wrote: > This becomes problematic if the real DMA device and the subdevices have > different addressing capabilities

Re: [PATCH 1/1] iommu/vt-d: use DMA domain for real DMA devices and subdevices

On Fri, Apr 10, 2020 at 9:22 AM Lu Baolu wrote: > This is caused by the fragile private domain implementation. We are in > process of removing it by enhancing the iommu subsystem with per-group > default domain. > > https://www.spinics.net/lists/iommu/msg42976.html > > So ultimately VMD

Re: [PATCH v4 0/3] Replace private domain with per-group default domain

patches on top of Joerg's branch and confirmed that they fix the issue discussed in the thread: [PATCH v2] iommu/vt-d: consider real PCI device when checking if mapping is needed (the patch there is no longer needed) Tested-by: Daniel Drake Thanks! __