Hi Eric,
> From: Auger Eric
> Sent: Thursday, August 13, 2020 8:53 PM
>
> Yi,
> On 7/28/20 8:27 AM, Liu Yi L wrote:
> > IOMMUs that support nesting translation needs report the capability info
> s/needs/need to
> > to userspace. It gives information about requirements the userspace needs
> > to
Hi Eric,
> From: Auger Eric
> Sent: Thursday, August 13, 2020 9:20 PM
>
> Hi Yi,
> On 7/28/20 8:27 AM, Liu Yi L wrote:
> > This patch exports iommu nesting capability info to user space through
> > VFIO. Userspace is expected to check this info for supported uAPIs (e.g.
> > PASID alloc/free, bind
Hi Eric,
> From: Auger Eric
> Sent: Thursday, August 13, 2020 11:07 PM
>
> Yi,
>
> On 7/28/20 8:27 AM, Liu Yi L wrote:
> > Shared Virtual Addressing (a.k.a Shared Virtual Memory) allows sharing
> > multiple process virtual address spaces with the device for simplified
> > programming model. PAS
Hi Eric,
> From: Auger Eric
> Sent: Thursday, August 13, 2020 11:07 PM
>
> Hi Yi,
>
> On 7/28/20 8:27 AM, Liu Yi L wrote:
> > From IOMMU p.o.v., PASIDs allocated and managed by external components
> > (e.g. VFIO) will be passed in for gpasid_bind/unbind operation. IOMMU
> > needs some knowledge
On Sat, 2020-05-30 at 16:10 +0800, Yong Wu wrote:
> MediaTek IOMMU has already added the device_link between the consumer
> and smi-larb device. If the mdp device call the pm_runtime_get_sync,
> the smi-larb's pm_runtime_get_sync also be called automatically.
>
> CC: Minghsiu Tsai
> CC: Houlong
On Fri, 2020-08-14 at 08:06 +0200, Christoph Hellwig wrote:
> On Sat, Aug 08, 2020 at 08:33:54AM +0200, Christoph Hellwig wrote:
> > On Fri, Aug 07, 2020 at 10:50:19AM +0200, Nicolas Saenz Julienne wrote:
> > > On Fri, 2020-08-07 at 07:21 +0200, Christoph Hellwig wrote:
> > > > On Thu, Aug 06, 2020
Now that we have an explanation to Amir's issue, we can re-spin this
series.
---
Changes since v3:
- Do not use memblock_start_of_DRAM()
Changes since v2:
- Go back to v1's behavior for patch #2
Changes since v1:
- Make cma_in_zone() more strict, GFP_KERNEL doesn't default to true
now
-
From: Christoph Hellwig
When allocating coherent pool memory for an IOMMU mapping we don't care
about the DMA mask. Move the guess for the initial GFP mask into the
dma_direct_alloc_pages and pass dma_coherent_ok as a function pointer
argument so that it doesn't get applied to the IOMMU case.
S
There is no guarantee to CMA's placement, so allocating a zone specific
atomic pool from CMA might return memory from a completely different
memory zone. To get around this double check CMA's placement before
allocating from it.
Signed-off-by: Nicolas Saenz Julienne
[hch: rebased, added a fallbac
I have experienced this this crash below on linux-next for the last few days
on my arm64 system. Linus' master branch today also has it.
Adding Robin and the iommu list as this seems to be in the dma-iommu
code.
root@ubuntu:/home/john# insmod nvme.ko
[148.254564] nvme :81:00.0: Adding to
On Fri, Aug 14, 2020 at 01:00:30PM +0100, John Garry wrote:
>
> > > I have experienced this this crash below on linux-next for the last few
> > > days
> > > on my arm64 system. Linus' master branch today also has it.
> > Adding Robin and the iommu list as this seems to be in the dma-iommu
> > cod
On 14/08/2020 13:08, Christoph Hellwig wrote:
[148.455065]__sg_alloc_table_from_pages+0xec/0x238
[148.459931]sg_alloc_table_from_pages+0x18/0x28
[148.464541]iommu_dma_alloc+0x474/0x678
[148.468455]dma_alloc_attrs+0xd8/0xf0
[148.472193]nvme_alloc_queue+0x114/0x160 [nvme]
[148.476798]nvme_reset_wor
On Fri, 14 Aug 2020 at 15:56, Nicolas Saenz Julienne
wrote:
>
> Now that we have an explanation to Amir's issue, we can re-spin this
> series.
Hi, Smoke tested (boots AOSP to UI with Touch/WiFi/BT working) on my
Poco F1 phone, with upstream commit 00e4db51259a (+ 30 odd out of
tree patches [1]) a
On 14/08/2020 14:07, John Garry wrote:
BTW, as for the DMA/sg scatterlist code, it so happens in this case that
we try the dma alloc for size=0 in nvme_alloc_queue() - I know an
allocation for size=0 makes no sense, but couldn't we bit a bit more
robust?
it's giving ZERO_SIZE_PTR, which we
Thanks,
applied to the dma-mapping tree.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
The mapping operations of the Tegra SMMU driver are subjected to a race
condition issues because SMMU Address Space isn't allocated and freed
atomically, while it should be. This patch makes the mapping operations
atomic, it fixes an accidentally released Host1x Address Space problem
which happens
On Thu, Aug 13, 2020 at 10:42 PM Christoph Hellwig wrote:
>
> The whole thing predates my involvement with the code, but I defintively
> think the patch from Hugh is a major improvement. But I would also
> have no problem with just removing it entirely.
I decided to just do both, since neither y
On Fri, 14 Aug 2020, Linus Torvalds wrote:
> On Thu, Aug 13, 2020 at 10:42 PM Christoph Hellwig wrote:
> >
> > The whole thing predates my involvement with the code, but I defintively
> > think the patch from Hugh is a major improvement. But I would also
> > have no problem with just removing it
On Fri, Aug 14, 2020 at 5:26 PM Hugh Dickins wrote:
>
> We used to rely on page count there, and on trylock_page() only; but
> there was at least one user whose app went wrong when occasionally we
> COWed the page, just because something else momentarily took a reference
> to it, or locked it. Ar
The default segment_boundary_mask was set to DMA_BIT_MAKS(32)
a decade ago by referencing SCSI/block subsystem, as a 32-bit
mask was good enough for most of the devices.
Now more and more drivers set dma_masks above DMA_BIT_MAKS(32)
while only a handful of them call dma_set_seg_boundary(). This
me
20 matches
Mail list logo
