Re: [PATCH v3 03/14] iommu/mediatek: Add device_link between the consumer and the larb devices

On Thu, 2020-03-05 at 13:14 +0800, Nicolas Boichat wrote: > On Tue, Sep 3, 2019 at 5:38 PM Yong Wu wrote: > > > > MediaTek IOMMU don't have its power-domain. all the consumer connect > > with smi-larb, then connect with smi-common. > > > > M4U > > | > > smi-common > >

Re: [PATCH v2] uacce: unmap remaining mmapping from user space

On 2020/3/6 上午9:51, Herbert Xu wrote: On Wed, Feb 26, 2020 at 03:12:06PM +0800, Zhangfei Gao wrote: When uacce parent device module is removed, user app may still keep the mmaped area, which can be accessed unsafely. When rmmod, Parent device driver will call uacce_remove, which unmap all

Re: [PATCH v2] uacce: unmap remaining mmapping from user space

On Wed, Feb 26, 2020 at 03:12:06PM +0800, Zhangfei Gao wrote: > When uacce parent device module is removed, user app may > still keep the mmaped area, which can be accessed unsafely. > When rmmod, Parent device driver will call uacce_remove, > which unmap all remaining mapping from user space for

Re: [PATCH v2] MAINTAINERS: add maintainers for uacce

On Wed, Feb 26, 2020 at 09:28:28AM +0800, Zhangfei Gao wrote: > Add Zhangfei Gao and Zhou Wang as maintainers for uacce > > Signed-off-by: Zhangfei Gao > Signed-off-by: Zhou Wang > --- > Add list, suggested by Dave > > MAINTAINERS | 12 > 1 file changed, 12 insertions(+) Patch

Possible bugs in iommu_map_sg()/iommu_map_dma_sg()

Hi all, I recently ran a 4GB+ allocation test case with my downstream older-version kernel, and found two possible bugs. I then saw the mainline code, yet don't find them getting fixed. However, I am not 100% sure that they are real practical bugs because I later figured out that my use case was

[PATCH] iommu/vt-d: fix RCU-list bugs in intel_iommu_init

There are several places traverse RCU-list without holding any lock in intel_iommu_init(). Fix them by acquiring dmar_global_lock. WARNING: suspicious RCU usage - drivers/iommu/intel-iommu.c:5216 RCU-list traversed in non-reader section!! other info that might

[PATCH -next] iommu/dmar: silence RCU-list debugging warnings

Similar to the commit 02d715b4a818 ("iommu/vt-d: Fix RCU list debugging warnings"), there are several other places that call list_for_each_entry_rcu() outside of an RCU read side critical section but with dmar_global_lock held. Silence those false positives as well.

Re: [PATCH v4 01/26] mm/mmu_notifiers: pass private data down to alloc_notifier()

On Mon, Feb 24, 2020 at 07:23:36PM +0100, Jean-Philippe Brucker wrote: > -static struct mmu_notifier *gru_alloc_notifier(struct mm_struct *mm) > +static struct mmu_notifier *gru_alloc_notifier(struct mm_struct *mm, void > *privdata) Pleae don't introduce any > 80 char lines. Not here, and not

Re: [rfc 6/6] dma-remap: double the default DMA coherent pool size

On Sun, Mar 01, 2020 at 04:05:27PM -0800, David Rientjes wrote: > When AMD memory encryption is enabled, some devices may used more than > 256KB/sec from the atomic pools. Double the default size to make the > original size and expansion more appropriate. > > This provides a slight optimization

Re: [rfc 5/6] dma-direct: atomic allocations must come from unencrypted pools

On Sun, Mar 01, 2020 at 04:05:23PM -0800, David Rientjes wrote: > When AMD memory encryption is enabled, all non-blocking DMA allocations > must originate from the atomic pools depending on the device and the gfp > mask of the allocation. > > Keep all memory in these pools unencrypted. > >

Re: [rfc 3/6] dma-remap: wire up the atomic pools depending on gfp mask

On Sun, Mar 01, 2020 at 04:05:16PM -0800, David Rientjes wrote: > > When allocating non-blockable memory, determine the optimal gfp mask of > the device and use the appropriate atomic pool. > > The coherent DMA mask will remain the same between allocation and free > and, thus, memory will be

Re: [rfc 2/6] dma-remap: add additional atomic pools to map to gfp mask

On Sun, Mar 01, 2020 at 04:05:13PM -0800, David Rientjes wrote: > The single atomic pool is allocated from the lowest zone possible since > it is guaranteed to be applicable for any DMA allocation. > > Devices may allocate through the DMA API but not have a strict reliance > on GFP_DMA memory.

Re: [PATCH v2 1/3] iommu/virtio: Add topology description to virtio-iommu config space

On Wed, Mar 04, 2020 at 10:54:49PM +0100, Joerg Roedel wrote: > On Wed, Mar 04, 2020 at 01:37:44PM -0800, Jacob Pan (Jun) wrote: > > + Mike and Erik who work closely on UEFI and ACPICA. > > > > Copy paste Erik's initial response below on how to get a new table, > > seems to confirm with the

Re: [PATCH v2 1/3] iommu/virtio: Add topology description to virtio-iommu config space

On Wed, Mar 04, 2020 at 10:50:02PM +0100, Joerg Roedel wrote: > On Wed, Mar 04, 2020 at 02:34:33PM -0500, Michael S. Tsirkin wrote: > > All these extra levels of indirection is one of the reasons > > hypervisors such as kata try to avoid ACPI. > > Platforms that don't use ACPI need another

Re: [iommu:arm/omap 4/4] drivers/gpu/drm/rockchip/rockchip_drm_gem.c:134:20: error: implicit declaration of function 'vmap'; did you mean 'bmap'?

On Thu, 5 Mar 2020 at 02:00, kbuild test robot wrote: > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git > arm/omap > head: e93a1695d7fb551376b1c1220a267d032b6ad159 > commit: e93a1695d7fb551376b1c1220a267d032b6ad159 [4/4] iommu: Enable compile > testing for some of

RE: [PATCH v2 1/3] iommu/virtio: Add topology description to virtio-iommu config space

> From: Jean-Philippe Brucker > Sent: Saturday, February 29, 2020 1:26 AM > > Platforms without device-tree do not currently have a method for > describing the vIOMMU topology. Provide a topology description embedded > into the virtio device. > > Use PCI FIXUP to probe the config space early,