On Tue, Jul 28, 2020 at 02:24:51PM -0400, Jim Quinlan wrote:
> I started using devm_kcalloc() but at least two reviewers convinced me
> to just use kcalloc(). In addition, when I was using devm_kcalloc()
> it was awkward because 'dev' is not available to this function.
>
> It comes down to whethe
> From: Alex Williamson
> Sent: Tuesday, July 28, 2020 11:54 PM
>
> On Mon, 27 Jul 2020 23:27:30 -0700
> Liu Yi L wrote:
>
> > This patch refactors the vfio_iommu_type1_ioctl() to use switch
> > instead of if-else, and each command got a helper function.
> >
> > Cc: Kevin Tian
> > CC: Jacob Pa
> From: Alex Williamson
> Sent: Wednesday, July 29, 2020 3:20 AM
>
[...]
> > +
> > +For example, IOTLB invalidations should always succeed. There is no
> > +architectural way to report back to the vIOMMU if the UAPI data is
> > +incompatible. If that happens, in order to guarantee IOMMU iosolatio
On Thu, 23 Jul 2020 10:25:35 -0700
Jacob Pan wrote:
> IOMMU UAPI is newly introduced to support communications between guest
> virtual IOMMU and host IOMMU. There has been lots of discussions on how
> it should work with VFIO UAPI and userspace in general.
>
> This document is intended to clarif
On Thu, 23 Jul 2020 10:25:39 -0700
Jacob Pan wrote:
> IOMMU user APIs are responsible for processing user data. This patch
> changes the interface such that user pointers can be passed into IOMMU
> code directly. Separate kernel APIs without user pointers are introduced
> for in-kernel users of t
Hi Christoph,
On Tue, Jul 28, 2020 at 8:33 AM Christoph Hellwig wrote:
>
> A few tiny nitpicks:
>
> The subject should have the dma-mapping prefix, this doesn't
> really touch the device core.
>
> > - rc = of_dma_get_range(np, &dma_addr, &paddr, &size);
> > + rc = of_dma_get_range(np, &ma
On Tue, Jul 28, 2020 at 11:05 AM Rob Herring wrote:
>
> On Fri, Jul 24, 2020 at 2:45 PM Jim Quinlan
> wrote:
> >
> > The new field 'dma_range_map' in struct device is used to facilitate the
> > use of single or multiple offsets between mapping regions of cpu addrs and
> > dma addrs. It subsumes
Fix W=1 compile warnings (invalid kerneldoc):
drivers/iommu/intel/dmar.c:389: warning: Function parameter or member
'header' not described in 'dmar_parse_one_drhd'
Signed-off-by: Krzysztof Kozlowski
---
drivers/iommu/intel/dmar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
The of_device_id is included unconditionally by of.h header and used
in the driver as well. Remove of_match_ptr to fix W=1 compile test
warning with !CONFIG_OF:
drivers/iommu/qcom_iommu.c:910:34: warning: 'qcom_iommu_of_match' defined
but not used [-Wunused-const-variable=]
910 | stati
Fix W=1 compile warnings (invalid kerneldoc):
drivers/iommu/amd/init.c:1586: warning: Function parameter or member 'ivrs'
not described in 'get_highest_supported_ivhd_type'
drivers/iommu/amd/init.c:1938: warning: Function parameter or member
'iommu' not described in 'iommu_update_intcapx
On Fri, 19 Jun 2020 09:20:01 +0100, Lorenzo Pieralisi wrote:
> This series is a v2 of a previous posting:
>
> v1 -> v2
>
> - Removed _rid() wrappers
> - Fixed !CONFIG_ACPI compilation issue
> - Converted of_pci_iommu_init() to use of_iommu_configure_dev_id()
>
> [...]
Applied to arm64 (for-next
Hi Sasha
On Mon, Jul 27, 2020 at 09:24:35PM +, Sasha Levin wrote:
> Hi
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag
> fixing commit: b16d0cb9e2fc ("iommu/vt-d: Always enable PASID/PRI PCI
> capabilities before ATS").
>
> The bot has
On Mon, 27 Jul 2020 23:27:30 -0700
Liu Yi L wrote:
> This patch refactors the vfio_iommu_type1_ioctl() to use switch instead of
> if-else, and each command got a helper function.
>
> Cc: Kevin Tian
> CC: Jacob Pan
> Cc: Alex Williamson
> Cc: Eric Auger
> Cc: Jean-Philippe Brucker
> Cc: Joer
On 7/9/2020 10:57 PM, Bjorn Andersson wrote:
> On Thu 09 Jul 08:50 PDT 2020, Laurentiu Tudor wrote:
>
>>
>>
>> On 7/9/2020 8:01 AM, Bjorn Andersson wrote:
>>> With many Qualcomm platforms not having functional S2CR BYPASS a
>>> temporary IOMMU domain, without translation, needs to be allocated
On Tue, Jul 28, 2020 at 06:18:41PM +0530, Amit Pundir wrote:
> > Oh well, this leaves me confused again. It looks like your setup
> > really needs a CMA in zone normal for the dma or dma32 pool.
>
> Anything I should look up in the downstream kernel/dts?
I don't have a good idea right now. Nico
On Tue, Jul 28, 2020 at 04:56:29PM +0200, Nicolas Saenz Julienne wrote:
> > + phys = gen_pool_virt_to_phys(pool, addr);
> > + if (!phys_addr_ok(dev, phys, size)) {
>
> Shoudn't we check if phys_addr_ok() != NULL?
Yes, we should. This also means the system that causes problems for
Amit isn't
On Tue, 28 Jul 2020, 07:16 Mike Rapoport, wrote:
> From: Mike Rapoport
>
> There are several occurrences of the following pattern:
>
> for_each_memblock(memory, reg) {
> start = __pfn_to_phys(memblock_region_memory_base_pfn(reg);
> end = __pfn_to_phys(memb
On Fri, Jul 24, 2020 at 2:45 PM Jim Quinlan wrote:
>
> The new field 'dma_range_map' in struct device is used to facilitate the
> use of single or multiple offsets between mapping regions of cpu addrs and
> dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
> capable of holdi
On Tue, 2020-07-28 at 12:47 +0200, Christoph Hellwig wrote:
> 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
On 07/28/20 at 05:15pm, Mike Rapoport wrote:
> On Tue, Jul 28, 2020 at 07:02:54PM +0800, Baoquan He wrote:
> > On 07/28/20 at 08:11am, Mike Rapoport wrote:
> > > From: Mike Rapoport
> > >
> > > numa_clear_kernel_node_hotplug() function first traverses numa_meminfo
> > > regions to set node ID in
On Tue, Jul 28, 2020 at 07:02:54PM +0800, Baoquan He wrote:
> On 07/28/20 at 08:11am, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > numa_clear_kernel_node_hotplug() function first traverses numa_meminfo
> > regions to set node ID in memblock.reserved and than traverses
> > memblock.reserve
On Tue, Jul 28, 2020 at 2:48 PM Lorenzo Pieralisi
wrote:
>
> On Wed, Jul 15, 2020 at 10:13:26AM +0100, Lorenzo Pieralisi wrote:
> > On Thu, Jul 09, 2020 at 10:35:14AM +0100, Lorenzo Pieralisi wrote:
> > > On Fri, Jun 19, 2020 at 09:20:06AM +0100, Lorenzo Pieralisi wrote:
> > > > Some HW devices ar
Some ACPI devices require access to the specified reserved memory
region.BIOS report the specified reserved memory region through
RMRR structures.Add analysis of ACPI device in RMRR and establish
identity mapping for ACPI device.
Signed-off-by: FelixCuioc
---
drivers/iommu/intel/dmar.c | 74 +++
On Tue, 28 Jul 2020 at 18:11, Christoph Hellwig wrote:
>
> On Tue, Jul 28, 2020 at 05:55:30PM +0530, Amit Pundir wrote:
> > On Tue, 28 Jul 2020 at 17:37, Christoph Hellwig wrote:
> > >
> > > On Tue, Jul 28, 2020 at 05:32:56PM +0530, Amit Pundir wrote:
> > > > > can you try these two patches? The
On Wed, Jul 15, 2020 at 10:13:26AM +0100, Lorenzo Pieralisi wrote:
> On Thu, Jul 09, 2020 at 10:35:14AM +0100, Lorenzo Pieralisi wrote:
> > On Fri, Jun 19, 2020 at 09:20:06AM +0100, Lorenzo Pieralisi wrote:
> > > Some HW devices are created as child devices of proprietary busses,
> > > that have a
On Tue, Jul 28, 2020 at 05:55:30PM +0530, Amit Pundir wrote:
> On Tue, 28 Jul 2020 at 17:37, Christoph Hellwig wrote:
> >
> > On Tue, Jul 28, 2020 at 05:32:56PM +0530, Amit Pundir wrote:
> > > > can you try these two patches? The first one makes sure we don't apply
> > > > physical address based
A few tiny nitpicks:
The subject should have the dma-mapping prefix, this doesn't
really touch the device core.
> - rc = of_dma_get_range(np, &dma_addr, &paddr, &size);
> + rc = of_dma_get_range(np, &map);
> + rc = PTR_ERR_OR_ZERO(map);
I don't think you need the PTR_ERR_OR_ZERO line
On Tue, 28 Jul 2020 at 17:37, Christoph Hellwig wrote:
>
> On Tue, Jul 28, 2020 at 05:32:56PM +0530, Amit Pundir wrote:
> > > can you try these two patches? The first one makes sure we don't apply
> > > physical address based checks for IOMMU allocations, and the second one
> > > is a slightly tw
On Tue, Jul 28, 2020 at 12:19:03PM +, Song Bao Hua (Barry Song) wrote:
> I am sorry I haven't got your point yet. Do you mean something like the below?
>
> arch/arm64/Kconfig:
> config CMDLINE
> string "Default kernel command string"
> - default ""
> + default "pernuma_cma=16M"
>
> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Tuesday, July 28, 2020 11:53 PM
> To: Song Bao Hua (Barry Song)
> Cc: h...@lst.de; m.szyprow...@samsung.com; robin.mur...@arm.com;
> w...@kernel.org; ganapatrao.kulka...@cavium.com;
> catalin.mari...@arm.com; io
On Tue, Jul 28, 2020 at 05:32:56PM +0530, Amit Pundir wrote:
> > can you try these two patches? The first one makes sure we don't apply
> > physical address based checks for IOMMU allocations, and the second one
> > is a slightly tweaked version of the patch from Nicolas to allow dipping
> > into
Hi Christoph,
On Tue, 28 Jul 2020 at 16:17, Christoph Hellwig wrote:
>
> Hi Amit,
>
> can you try these two patches? The first one makes sure we don't apply
> physical address based checks for IOMMU allocations, and the second one
> is a slightly tweaked version of the patch from Nicolas to allo
It seems that I didn't rebase the patchset properly. There are some
build test errors.
Sorry about that. Please kindly ignore those rebase issues. I'll fix
them in the next version.
On Tue, Jul 28, 2020 at 1:01 PM Claire Chang wrote:
>
> This series implements mitigations for lack of DMA access
Looks ok to me, but before I pick the series up in the dma-mapping tree
I really want an ACK from the arm64 maintainers.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Fri, Jul 24, 2020 at 01:13:43AM +1200, Barry Song wrote:
> +config CMA_PERNUMA_SIZE_MBYTES
> + int "Size in Mega Bytes for per-numa CMA areas"
> + depends on NUMA
> + default 16 if ARM64
> + default 0
> + help
> + Defines the size (in MiB) of the per-numa memory area fo
* Mike Rapoport wrote:
> On Tue, Jul 28, 2020 at 12:44:40PM +0200, Ingo Molnar wrote:
> >
> > * Mike Rapoport wrote:
> >
> > > From: Mike Rapoport
> > >
> > > numa_clear_kernel_node_hotplug() function first traverses numa_meminfo
> > > regions to set node ID in memblock.reserved and than t
On 07/28/20 at 08:11am, Mike Rapoport wrote:
> From: Mike Rapoport
>
> numa_clear_kernel_node_hotplug() function first traverses numa_meminfo
> regions to set node ID in memblock.reserved and than traverses
> memblock.reserved to update reserved_nodemask to include node IDs that were
> set in the
On Tue, Jul 28, 2020 at 12:44:40PM +0200, Ingo Molnar wrote:
>
> * Mike Rapoport wrote:
>
> > From: Mike Rapoport
> >
> > numa_clear_kernel_node_hotplug() function first traverses numa_meminfo
> > regions to set node ID in memblock.reserved and than traverses
> > memblock.reserved to update re
Hi Amit,
can you try these two patches? The first one makes sure we don't apply
physical address based checks for IOMMU allocations, and the second one
is a slightly tweaked version of the patch from Nicolas to allow dipping
into the CMA areas for allocations to expand the atomic pools.
_
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.
Signed-off-by: Christoph He
From: Nicolas Saenz Julienne
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
* Mike Rapoport wrote:
> From: Mike Rapoport
>
> numa_clear_kernel_node_hotplug() function first traverses numa_meminfo
> regions to set node ID in memblock.reserved and than traverses
> memblock.reserved to update reserved_nodemask to include node IDs that were
> set in the first loop.
>
>
On Tue, Jul 28, 2020 at 11:30:32AM +0200, Nicolas Saenz Julienne wrote:
> On Tue, 2020-07-28 at 11:13 +0200, Christoph Hellwig wrote:
> > On Mon, Jul 27, 2020 at 07:56:56PM +0200, Nicolas Saenz Julienne wrote:
> > > Hi Christoph,
> > > thanks for having a look at this!
> > >
> > > On Fri, 2020-07-
On Tue, 2020-07-28 at 11:13 +0200, Christoph Hellwig wrote:
> On Mon, Jul 27, 2020 at 07:56:56PM +0200, Nicolas Saenz Julienne wrote:
> > Hi Christoph,
> > thanks for having a look at this!
> >
> > On Fri, 2020-07-24 at 15:41 +0200, Christoph Hellwig wrote:
> > > Yes, the iommu is an interesting c
On Mon, Jul 27, 2020 at 07:56:56PM +0200, Nicolas Saenz Julienne wrote:
> Hi Christoph,
> thanks for having a look at this!
>
> On Fri, 2020-07-24 at 15:41 +0200, Christoph Hellwig wrote:
> > Yes, the iommu is an interesting case, and the current code is
> > wrong for that.
>
> Care to expand on
On Mon, Jul 27, 2020 at 10:12 PM Mike Rapoport wrote:
>
> From: Mike Rapoport
>
> The function free_highpages() in both arm and xtensa essentially open-code
> for_each_free_mem_range() loop to detect high memory pages that were not
> reserved and that should be initialized and passed to the buddy
46 matches
Mail list logo
