Hi,
On 11/12/18 3:20 PM, Liu, Yi L wrote:
boun...@lists.linux-foundation.org] On Behalf Of Lu Baolu
Sent: Monday, November 12, 2018 2:40 PM
Subject: [PATCH v2 1/1] iommu/vtd: Cleanup dma_remapping.h header
Commit e61d98d8dad00 ("x64, x2apic/intr-remap: Intel vt-d, IOMMU
code reorganization") mo
> boun...@lists.linux-foundation.org] On Behalf Of Lu Baolu
> Sent: Monday, November 12, 2018 2:40 PM
> Subject: [PATCH v2 1/1] iommu/vtd: Cleanup dma_remapping.h header
>
> Commit e61d98d8dad00 ("x64, x2apic/intr-remap: Intel vt-d, IOMMU
> code reorganization") moved dma_remapping.h from drivers/
This adds the Intel vt-d specific ops to allocate and free a
pasid value.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Liu Yi L
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/
This uses global pasid allocator in the Intel iommu driver.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Liu Yi L
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 20 +++-
drivers/iommu/intel-pasid.c | 36
drivers/iom
If Intel IOMMU runs in caching mode, a.k.a. virtual IOMMU, the
IOMMU driver should rely on the emulation software to allocate
and free PASID IDs. The Intel vt-d spec revision 3.0 defines a
register set to support this. This includes a capability register,
a virtual command register and a virtual re
This adds the Intel vt-d specific ops to initialize a PASID
consumer.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Liu Yi L
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/iommu/i
This adds APIs for IOMMU drivers and device drivers to manage
the PASIDs used for DMA transfer and translation. It bases on
I/O ASID allocator for PASID namespace management and relies
on vendor specific IOMMU drivers for paravirtual PASIDs.
Below APIs are added:
* iommu_pasid_init(pasid)
- Ini
This adds an uniformed API set for global PASIDs used by IOMMU
and device drivers which depend on IOMMU. It works for drivers
running on bare metal, full virtualized environments and para-
virtualized environment.
When PASID requests come from components running on the bare
metal hardware, the req
Hi,
On 11/12/18 2:40 PM, Lu Baolu wrote:
Commit e61d98d8dad00 ("x64, x2apic/intr-remap: Intel vt-d, IOMMU
code reorganization") moved dma_remapping.h from drivers/pci/ to
current place. It is entirely VT-d specific, but uses a generic
name. This merges dma_remapping.h with include/linux/intel-io
Commit e61d98d8dad00 ("x64, x2apic/intr-remap: Intel vt-d, IOMMU
code reorganization") moved dma_remapping.h from drivers/pci/ to
current place. It is entirely VT-d specific, but uses a generic
name. This merges dma_remapping.h with include/linux/intel-iommu.h
and removes dma_remapping.h as the res
On 11/12/2018 09:40 AM, Anshuman Khandual wrote:
>
>
> On 11/12/2018 09:27 AM, Joseph Qi wrote:
>> For ocfs2 part, node means host in the cluster, not NUMA node.
>>
>
> Does not -1 indicate an invalid node which can never be present ?
>
My bad, got it wrong. Seems like this is nothing to do
On 11/12/2018 09:27 AM, Joseph Qi wrote:
> For ocfs2 part, node means host in the cluster, not NUMA node.
>
Does not -1 indicate an invalid node which can never be present ?
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxf
For ocfs2 part, node means host in the cluster, not NUMA node.
Thanks,
Joseph
On 18/11/12 10:41, Anshuman Khandual wrote:
> At present there are multiple places where invalid node number is encoded
> as -1. Even though implicitly understood it is always better to have macros
> in there. Replace t
At present there are multiple places where invalid node number is encoded
as -1. Even though implicitly understood it is always better to have macros
in there. Replace these open encodings for an invalid node number with the
global macro NUMA_NO_NODE. This helps remove NUMA related assumptions like
Hi,
On 11/10/18 4:35 PM, Christoph Hellwig wrote:
On Sat, Nov 10, 2018 at 03:08:44PM +0800, Lu Baolu wrote:
Commit e61d98d8dad00 ("x64, x2apic/intr-remap: Intel vt-d, IOMMU
code reorganization") moved dma_remapping.h from drivers/pci/ to
current place. It is entirely VT-d specific, but uses a g
3.16.61-rc1 review patch. If anyone has any objections, please let me know.
--
From: Dmitry Safonov
commit 6c50d79f66382d78918a768374839d6d1b606d3f upstream.
There is a ratelimit for printing, but it's incremented each time the
cpu recives dmar fault interrupt. While one inter
SLAB_CACHE_DMA32 is only available after explicit kmem_cache_create calls,
no default cache is created for kmalloc. Add a test in check_slab_flags
for this.
Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
Signed-off-by: Nicolas Boichat
---
include/linux/slab.h | 2 ++
mm/interna
Remove duplicated code between slab and slub, and will make it
easier to make the test more complicated in the next commits.
Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
Signed-off-by: Nicolas Boichat
---
mm/internal.h | 17 +++--
mm/slab.c | 8 +---
mm/sl
For level 1/2 pages, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32
is defined (e.g. on arm64 platforms).
For level 2 pages, allocate a slab cache in SLAB_CACHE_DMA32.
Also, print an error when the physical address does not fit in
32-bit, to make debugging easier in the future.
Fixes: ad67f5a6545
This is a follow-up to the discussion in [1], to make sure that the page
tables allocated by iommu/io-pgtable-arm-v7s are contained within 32-bit
physical address space.
[1] https://lists.linuxfoundation.org/pipermail/iommu/2018-November/030876.html
Fixes since v1:
- Add support for SLAB_CACHE_D
20 matches
Mail list logo
