On Mon, Aug 3, 2020 at 8:03 AM Dave Hansen wrote:
>
> On 7/31/20 4:34 PM, Andy Lutomirski wrote:
> >> Thomas suggested to provide a reason for the #GP caused by executing ENQCMD
> >> without a valid PASID value programmed. #GP error codes are 16 bits and all
> >> 16 bits are taken. Refer to SDM
On 01/08/2020 08:47, Barry Song wrote:
Polling by MSI isn't necessarily faster than polling by SEV. Tests on
hi1620 show hns3 100G NIC network throughput can improve from 25G to
27G if we disable MSI polling while running 16 netperf threads sending
UDP packets in size 32KB.
BTW, Do we have any
On Mon, Aug 3, 2020 at 9:37 AM Dave Hansen wrote:
>
> On 8/3/20 8:12 AM, Andy Lutomirski wrote:
> > I could easily be convinced that the PASID fixup is so trivial and so
> > obviously free of misfiring in a way that causes an infinite loop that
> > this code is fine. But I think we first need to
On Mon, Aug 03, 2020 at 08:12:18AM -0700, Andy Lutomirski wrote:
> On Mon, Aug 3, 2020 at 8:03 AM Dave Hansen wrote:
> >
> > On 7/31/20 4:34 PM, Andy Lutomirski wrote:
> > >> Thomas suggested to provide a reason for the #GP caused by executing
> > >> ENQCMD
> > >> without a valid PASID value
Hi Claire and Rob,
On Mon, Aug 3, 2020 at 4:26 PM Claire Chang wrote:
>
> On Sat, Aug 1, 2020 at 4:58 AM Rob Herring wrote:
> >
> > On Tue, Jul 28, 2020 at 01:01:39PM +0800, Claire Chang wrote:
> > > Introduce the new compatible string, device-swiotlb-pool, for restricted
> > > DMA. One can
Hi, Andy,
On Fri, Jul 31, 2020 at 06:28:37PM -0700, Andy Lutomirski wrote:
> On Mon, Jul 13, 2020 at 4:48 PM Fenghua Yu wrote:
> >
> > A #GP fault is generated when ENQCMD instruction is executed without
> > a valid PASID value programmed in the current thread's PASID MSR. The
> > #GP fault
On 7/31/20 4:34 PM, Andy Lutomirski wrote:
>> Thomas suggested to provide a reason for the #GP caused by executing ENQCMD
>> without a valid PASID value programmed. #GP error codes are 16 bits and all
>> 16 bits are taken. Refer to SDM Vol 3, Chapter 16.13 for details. The other
>> choice was to
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.
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
---
Changes since v1:
-
Now that we have an explanation to Amir's issue, I took the liberty to
respin the previous dma-pool fixes series with some changes/fixes of my
own.
---
Changes since v1:
- Make cma_in_zone() more strict, GFP_KERNEL doesn't default to true
now
- Check if phys_addr_ok() exists prior calling
On 8/3/20 8:12 AM, Andy Lutomirski wrote:
> I could easily be convinced that the PASID fixup is so trivial and so
> obviously free of misfiring in a way that causes an infinite loop that
> this code is fine. But I think we first need to answer the bigger
> question of why we're doing a lazy fixup
On 8/3/20 10:16 AM, Andy Lutomirski wrote:
> - TILE: genuinely per-thread, but it's expensive so it's
> lazy-loadable. But the lazy-load mechanism reuses #NM, and it's not
> fully disambiguated from the other use of #NM. So it sort of works,
> but it's gross.
For those playing along at home,
On 7/3/2020 7:47 PM, vji...@codeaurora.org wrote:
> From: Vijayanand Jitta
>
> When ever an iova alloc request fails we free the iova
> ranges present in the percpu iova rcaches and then retry
> but the global iova rcache is not freed as a result we could
> still see iova alloc failure even
On 7/3/2020 7:47 PM, vji...@codeaurora.org wrote:
> From: Vijayanand Jitta
>
> When ever a new iova alloc request comes iova is always searched
> from the cached node and the nodes which are previous to cached
> node. So, even if there is free iova space available in the nodes
> which are
On Sat, Aug 1, 2020 at 1:17 PM Nicolas Saenz Julienne
wrote:
>
> Hi Jim, here's some comments after testing your series against RPi4.
>
> On Fri, 2020-07-24 at 16:33 -0400, Jim Quinlan wrote:
> > The new field 'dma_range_map' in struct device is used to facilitate the
> > use of single or
Hi baolu,
dmar_acpi_dev_scope_init() parse ANDD structure and enumerated
namespaces device in DRHD.
But the namespace device in RMRR is not enumerated, right?
Best regards
Felix cui-oc
-邮件原件-
发件人: FelixCui-oc
发送时间: 2020年8月3日 17:02
收件人: 'Lu Baolu' ;
Note that this adds a select to drivers/iommu/Kconfig symbols which moves
to drivers/iommu/intel/Kconfig in the iommu tree.
The following changes since commit d9765e41d8e9ea2251bf73735a2895c8bad546fc:
dma-pool: do not allocate pool memory from CMA (2020-07-14 15:46:32 +0200)
are available in
On Sat, Aug 1, 2020 at 4:58 AM Rob Herring wrote:
>
> On Tue, Jul 28, 2020 at 01:01:39PM +0800, Claire Chang wrote:
> > Introduce the new compatible string, device-swiotlb-pool, for restricted
> > DMA. One can specify the address and length of the device swiotlb memory
> > region by
> On Aug 3, 2020, at 10:34 AM, Dave Hansen wrote:
>
> On 8/3/20 10:16 AM, Andy Lutomirski wrote:
>> - TILE: genuinely per-thread, but it's expensive so it's
>> lazy-loadable. But the lazy-load mechanism reuses #NM, and it's not
>> fully disambiguated from the other use of #NM. So it sort
Add support to create a io-pgtable for use by targets that support
per-instance pagetables. In order to support per-instance pagetables the
GPU SMMU device needs to have the qcom,adreno-smmu compatible string and
split pagetables enabled.
Signed-off-by: Jordan Crouse
---
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 holding a single uniform offset and had no region bounds
checking.
Add support for allocating private address space instances. Targets that
support per-context pagetables should implement their own function to
allocate private address spaces.
The default will return a pointer to the global address space.
Signed-off-by: Jordan Crouse
---
Add a special implementation for the SMMU attached to most Adreno GPU
target triggered from the qcom,adreno-smmu compatible string.
The new Adreno SMMU implementation will enable split pagetables
(TTBR1) for the domain attached to the GPU device (SID 0) and
hard code it context bank 0 so the GPU
Add support for using per-instance pagetables if all the dependencies are
available.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 53 +++
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 1 +
drivers/gpu/drm/msm/msm_ringbuffer.h | 1 +
3 files
Add domain attribute DOMAIN_ATTR_PGTABLE_CFG. This will be used by
arm-smmu to share the current pagetable configuration with the
leaf driver and to allow the leaf driver to set up a new pagetable
configuration under certain circumstances.
Signed-off-by: Jordan Crouse
---
include/linux/iommu.h
Do a bit of prep work to add the upcoming adreno-smmu implementation.
Add an hook to allow the implementation to choose which context banks
to allocate. Then, add domain_attr_get / domain_attr_set hooks to allow
for implementation specific domain attributes.
Move some of the common structs to
Enable TTBR1 for a context bank if IO_PGTABLE_QUIRK_ARM_TTBR1 is selected
by the io-pgtable configuration.
Signed-off-by: Jordan Crouse
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 21 -
drivers/iommu/arm/arm-smmu/arm-smmu.h | 25 +++--
2 files changed,
Each submitqueue is attached to a context. Add a pointer to the
context to the submitqueue at create time and refcount it so
that it stays around through the life of the queue.
GPU submissions can access the active context via the submitqueue
instead of requiring it to be passed around from
Use the aperture settings from the IOMMU domain to set up the virtual
address range for the GPU. This allows us to transparently deal with
IOMMU side features (like split pagetables).
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 13 +++--
Set the qcom,adreno-smmu compatible string for the GPU SMMU to enable
split pagetables and per-instance pagetables for drm/msm.
Signed-off-by: Jordan Crouse
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
This series adds an Adreno SMMU implementation to arm-smmu to allow GPU hardware
pagetable switching.
The Adreno GPU has built in capabilities to switch the TTBR0 pagetable during
runtime to allow each individual instance or application to have its own
pagetable. In order to take advantage of
Every Qcom Adreno GPU has an embedded SMMU for its own use. These
devices depend on unique features such as split pagetables,
different stall/halt requirements and other settings. Identify them
with a compatible string so that they can be identified in the
arm-smmu implementation specific code.
Construct the io-pgtable config before calling the implementation specific
init_context function and pass it so the implementation specific function
can get a chance to change it before the io-pgtable is created.
Signed-off-by: Jordan Crouse
---
drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 3
On Mon, 3 Aug 2020, Christoph Hellwig wrote:
> On Sun, Aug 02, 2020 at 09:14:41PM -0700, David Rientjes wrote:
> > Christoph: since we have atomic DMA coherent pools in 5.8 now, recall our
> > previous discussions, including Greg KH, regarding backports to stable
> > trees (we are interested in
Patchset Summary:
Enhance a PCIe host controller driver. Because of its unusual design
we are foced to change dev->dma_pfn_offset into a more general role
allowing multiple offsets. See the 'v1' notes below for more info.
v10:
Commit: "device-mapping: Introduce DMA range map,
> -Original Message-
> From: John Garry
> Sent: Tuesday, August 4, 2020 3:34 AM
> To: Song Bao Hua (Barry Song) ; w...@kernel.org;
> robin.mur...@arm.com; j...@8bytes.org; iommu@lists.linux-foundation.org
> Cc: Zengtao (B) ;
> linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v3]
> Sounds like things are progressing nicely for a while there, presumably
> until the next time the display is being refreshed.
>
> Would you be willing to try out the following work in progress:
> https://lore.kernel.org/linux-arm-msm/20200717001619.325317-1-bjorn.anders...@linaro.org/
I sure
Hi Felix,
On 2020/8/3 17:41, FelixCui-oc wrote:
Hi baolu,
dmar_acpi_dev_scope_init() parse ANDD structure and enumerated
namespaces device in DRHD.
Yes.
But the namespace device in RMRR is not enumerated, right?
It should be probed in
Hi baolu ,
When creating a identity mapping for a namespace device in
RMRR, you need to add the namespace device to the rmrr->device[] , right?
The dmar_acpi_bus_add_dev() in patch adds the enumeration of
the namespace device in RMRR. This is similar to
Currently, there is no other option to change the lower limit of
IOVA for any device than calling iova_init_domain(), but the
said function will re-init whole domain and also doesn't track
the previously allocated IOVA before re-initing the domain.
There are cases where the device might not
Hi,
On 2020/8/3 12:40, FelixCui-oc wrote:
Hi baolu:
Some ACPI devices need to issue dma requests to access the
reserved memory area.
So bios uses the device scope type ACPI_NAMESPACE_DEVICE in
RMRR to report these ACPI devices.
At present, there
Hi baolu ,
Yes ,that's right.
This patch is to achieve acpi namespace devices to access the
RMRR region.
Best regards
Felix cui
-邮件原件-
发件人: Lu Baolu
发送时间: 2020年8月3日 14:19
收件人: FelixCui-oc ; Joerg Roedel ;
iommu@lists.linux-foundation.org;
On Sun, Aug 02, 2020 at 09:14:41PM -0700, David Rientjes wrote:
> Christoph: since we have atomic DMA coherent pools in 5.8 now, recall our
> previous discussions, including Greg KH, regarding backports to stable
> trees (we are interested in 5.4 and 5.6) of this support for the purposes
> of
On Sun, Aug 02, 2020 at 02:14:06PM -0500, Bjorn Helgaas wrote:
> But what guarantees that a PCI config register cannot contain ~0?
> If there's something about that in the spec I'd love to know where it
> is because it would simplify a lot of things.
There isn't. An we even have cases like the
Hi baolu:
"The namespace devices are enumerated in
probe_acpi_namespace_devices().
It calls iommu_probe_device() to process the enumeration and
setup the identity mappings."
This situation only applies to the physical node of the
On 2020/8/3 14:52, FelixCui-oc wrote:
Hi baolu ,
Yes ,that's right.
This patch is to achieve acpi namespace devices to access the
RMRR region.
The namespace devices are enumerated in probe_acpi_namespace_devices().
It calls iommu_probe_device() to process the
46 matches
Mail list logo
