tches 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!
_
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 probl
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 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 and
> 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 f
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 trans
ice 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
ice 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
ice 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
---
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.
> >
> >
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-
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 convers
Signed-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&m=156015271021615&w=2)
This patch creates PCI devices in the same way as VMD, and hence
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: iommu@lists.linux-foundation.org; amd-...@lists.freedesktop.org;
>>Deucher, Ale
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
http://marc.info/?
On Wed, Apr 5, 2017 at 9:01 AM, Nath, Arindam 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; Deucher, Alexander; Bridgman, John; a
On Thu, Mar 30, 2017 at 12:23 AM, Nath, Arindam wrote:
> Daniel, did you get chance to test this patch?
Not yet. Should we test it alone or alongside "PCI: Blacklist AMD
Stoney GPU devices for ATS"?
Thanks
Daniel
___
iommu mailing list
iommu@lists.linu
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
>
> The idea behind flush queues i
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 wrote:
>> > I am p
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 over and over:
> >
> > AMD
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
21 matches
Mail list logo
