On 28/10/20 22:20, Arnd Bergmann wrote:
> Avoid this by renaming the global 'apic' variable to the more descriptive
> 'x86_system_apic'. It was originally called 'genapic', but both that
> and the current 'apic' seem to be a little overly generic for a global
> variable.
The 'apic' affects only
On Thu, Oct 29, 2020 at 8:04 AM Paolo Bonzini wrote:
>
> On 28/10/20 22:20, Arnd Bergmann wrote:
> > Avoid this by renaming the global 'apic' variable to the more descriptive
> > 'x86_system_apic'. It was originally called 'genapic', but both that
> > and the current 'apic' seem to be a little
If of_find_device_by_node() failed in rk_iommu_of_xlate(), null pointer
dereference will be triggered. Thus return error code if
of_find_device_by_node() failed.
Fixes: 5fd577c3eac3("iommu/rockchip: Use OF_IOMMU to attach devices
automatically")
Signed-off-by: Yu Kuai
---
If of_find_device_by_node() failed in sun50i_iommu_of_xlate(), null
pointer dereference will be triggered. Thus return error code if
of_find_device_by_node() failed.
Fixes: 4100b8c229b3("iommu: Add Allwinner H6 IOMMU driver")
Signed-off-by: Yu Kuai
---
drivers/iommu/sun50i-iommu.c | 3 +++
1
On 2020-10-29 09:22, Yu Kuai wrote:
If of_find_device_by_node() failed in sun50i_iommu_of_xlate(), null
pointer dereference will be triggered. Thus return error code if
of_find_device_by_node() failed.
Again, by what means can that ever actually happen?
Robin.
Fixes: 4100b8c229b3("iommu:
On 20-10-28 10:13:56, Jean-Philippe Brucker wrote:
> Hi,
>
> On Wed, Oct 28, 2020 at 09:36:57AM +0800, Yi Sun wrote:
> > From: Jacob Pan
> >
> > original code fails when LAST_PAGE is set in flags.
>
> LAST_PAGE is not documented to be a valid flags for page_response.
> So isn't failing the
On Thu, Oct 29, 2020 at 05:22:44PM +0800, Yu Kuai wrote:
> If of_find_device_by_node() failed in sun50i_iommu_of_xlate(), null
> pointer dereference will be triggered. Thus return error code if
> of_find_device_by_node() failed.
>
> Fixes: 4100b8c229b3("iommu: Add Allwinner H6 IOMMU driver")
>
Alexey Kardashevskiy writes:
> So far we have been using huge DMA windows to map all the RAM available.
> The RAM is normally mapped to the VM address space contiguously, and
> there is always a reasonable upper limit for possible future hot plugged
> RAM which makes it easy to map all RAM via
Alexey Kardashevskiy writes:
> On 29/10/2020 11:40, Michael Ellerman wrote:
>> Alexey Kardashevskiy writes:
>>> @@ -1126,7 +1129,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct
>>> device_node *pdn)
>>>
>>> mutex_lock(_window_init_mutex);
>>>
>>> - dma_addr =
On 2020-10-29 09:22, Yu Kuai wrote:
If of_find_device_by_node() failed in rk_iommu_of_xlate(), null pointer
dereference will be triggered. Thus return error code if
of_find_device_by_node() failed.
How can that happen? (Given that ".suppress_bind_attrs = true")
Robin.
Fixes:
The iommu_ops will only take effect when INTEL_IOMMU_SCALABLE_IOV kernel
option is selected. It applies to any device passthrough framework which
implements an underlying bus for the subdevices.
- Subdevice probe:
When a subdevice is created and added to the bus, iommu_probe_device()
will be
Move mdev bus registration earlier than IOMMU probe processing so that
the IOMMU drivers could be able to set iommu_ops for the mdev bus. This
only applies when vfio-mdev module is setected to be built-in.
Signed-off-by: Lu Baolu
---
drivers/vfio/mdev/mdev_core.c | 4
1 file changed, 4
So that they could be used in other files as well. No functional changes.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/iommu.c | 74 +++--
include/linux/intel-iommu.h | 49
2 files changed, 62 insertions(+), 61 deletions(-)
diff --git
The aux-domain apis were designed for macro driver where the subdevices
are created and used inside a device driver. Use the device's bus iommu
ops instead of that in iommu domain for various callbacks.
Signed-off-by: Lu Baolu
---
drivers/iommu/iommu.c | 16 ++--
1 file changed, 10
Hi Joerg and Alex,
A description of purpose for this series could be found here.
https://lore.kernel.org/linux-iommu/20200901033422.22249-1-baolu...@linux.intel.com/
The previous version was posted here.
https://lore.kernel.org/linux-iommu/20200922061042.31633-1-baolu...@linux.intel.com/
This
With the IOMMU driver registering iommu_ops for the mdev_bus, the IOMMU
operations on an mdev could be done in the same way as any normal device
(for example, PCI/PCIe). There's no need to distinguish an mdev from
others for iommu operations. Remove the unnecessary code.
Signed-off-by: Lu Baolu
> From: Lu Baolu
> Sent: Friday, October 30, 2020 12:58 PM
>
> The aux-domain apis were designed for macro driver where the subdevices
> are created and used inside a device driver. Use the device's bus iommu
> ops instead of that in iommu domain for various callbacks.
IIRC there are only two
On 2020/10/29 18:08, Robin Murphy wrote:
On 2020-10-29 09:22, Yu Kuai wrote:
If of_find_device_by_node() failed in rk_iommu_of_xlate(), null pointer
dereference will be triggered. Thus return error code if
of_find_device_by_node() failed.
How can that happen? (Given that
On 2020-10-29 13:19, yukuai (C) wrote:
On 2020/10/29 18:08, Robin Murphy wrote:
On 2020-10-29 09:22, Yu Kuai wrote:
If of_find_device_by_node() failed in rk_iommu_of_xlate(), null pointer
dereference will be triggered. Thus return error code if
of_find_device_by_node() failed.
How can that
On Mon, 19 Oct 2020 11:23:20 -0700, Bjorn Andersson wrote:
> This is the revised fourth attempt of inheriting the stream mapping for
> the framebuffer on many Qualcomm platforms, in order to not hit
> catastrophic faults during arm-smmu initialization.
>
> The new approach does, based on Robin's
On 2020-10-27 03:53, Barry Song wrote:
Nowadays, there are increasing requirements to benchmark the performance
of dma_map and dma_unmap particually while the device is attached to an
IOMMU.
This patch enables the support. Users can run specified number of threads
to do dma_map_page and
From: Arnd Bergmann
> Sent: 28 October 2020 21:21
>
> From: Arnd Bergmann
>
> There are hundreds of warnings in a W=2 build about a local
> variable shadowing the global 'apic' definition:
>
> arch/x86/kvm/lapic.h:149:65: warning: declaration of 'apic' shadows a global
> declaration
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Friday, October 30, 2020 8:38 AM
> To: Song Bao Hua (Barry Song) ;
> iommu@lists.linux-foundation.org; h...@lst.de; m.szyprow...@samsung.com
> Cc: j...@8bytes.org; w...@kernel.org; sh...@kernel.org; Linuxarm
On Thu, Oct 29 2020 at 17:59, Paolo Bonzini wrote:
> On 29/10/20 17:56, Arvind Sankar wrote:
>>> For those two just add:
>>> struct apic *apic = x86_system_apic;
>>> before all the assignments.
>>> Less churn and much better code.
>>>
>> Why would it be better code?
>>
>
> I think he means
On Thu, Oct 29, 2020 at 09:41:13PM +0100, Thomas Gleixner wrote:
> On Thu, Oct 29 2020 at 17:59, Paolo Bonzini wrote:
> > On 29/10/20 17:56, Arvind Sankar wrote:
> >>> For those two just add:
> >>> struct apic *apic = x86_system_apic;
> >>> before all the assignments.
> >>> Less churn and much
From: Arvind Sankar
> Sent: 29 October 2020 21:35
>
> On Thu, Oct 29, 2020 at 09:41:13PM +0100, Thomas Gleixner wrote:
> > On Thu, Oct 29 2020 at 17:59, Paolo Bonzini wrote:
> > > On 29/10/20 17:56, Arvind Sankar wrote:
> > >>> For those two just add:
> > >>> struct apic *apic =
On 2020-10-29 15:41, Shameer Kolothum wrote:
With the introduction of def_domain_type in iommu_ops, vendor
drivers can now inform the iommu generic layer about any specific
default domain requirement for a device. Any pci dev marked as
untrusted is now prevented from having an IDENTITY mapping
Arnd,
On Thu, Oct 29 2020 at 10:51, Arnd Bergmann wrote:
> On Thu, Oct 29, 2020 at 8:04 AM Paolo Bonzini wrote:
>> On 28/10/20 22:20, Arnd Bergmann wrote:
>> > Avoid this by renaming the global 'apic' variable to the more descriptive
>> > 'x86_system_apic'. It was originally called 'genapic',
On Thu, Oct 29, 2020 at 05:59:54PM +0100, Paolo Bonzini wrote:
> On 29/10/20 17:56, Arvind Sankar wrote:
> >> For those two just add:
> >>struct apic *apic = x86_system_apic;
> >> before all the assignments.
> >> Less churn and much better code.
> >>
> > Why would it be better code?
> >
>
>
We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
incorporating masters that can address less than 32 bits of DMA, in
particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has
peripherals that can only address up to 1 GB (and its PCIe host
bridge can only access the
We can't really list every setup in common code. On top of that they are
unlikely to stay true for long as things change in the arch trees
independently of this comment.
Suggested-by: Christoph Hellwig
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Christoph Hellwig
---
Introduce a test for of_dma_get_max_cup_address(), it uses the same DT
data as the rest of dma-ranges unit tests.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Rob Herring
---
Changes since v3:
- Remove HAS_DMA guards
drivers/of/unittest.c | 18 ++
1 file changed, 18
Using two distinct DMA zones turned out to be problematic. Here's an
attempt go back to a saner default.
I tested this on both a RPi4 and QEMU.
---
Changes since v4:
- Fix of_dma_get_max_cpu_address() so it returns the last addressable
addres, not the limit
Changes since v3:
- Drop patch
From: Ard Biesheuvel
We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
incorporating masters that can address less than 32 bits of DMA, in
particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has
peripherals that can only address up to 1 GB (and its PCIe host
bridge
zone_dma_bits's initialization happens earlier that it's actually
needed, in arm64_memblock_init(). So move it into the more suitable
zone_sizes_init().
Signed-off-by: Nicolas Saenz Julienne
Tested-by: Jeremy Linton
---
arch/arm64/mm/init.c | 7 ++-
1 file changed, 2 insertions(+), 5
crashkernel might reserve memory located in ZONE_DMA. We plan to delay
ZONE_DMA's initialization after unflattening the devicetree and ACPI's
boot table initialization, so move it later in the boot process.
Specifically into mem_init(), this is the last place crashkernel will be
able to reserve
Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
physical address addressable by all DMA masters in the system. It's
specially useful for setting memory zones sizes at early boot time.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v4:
- Return max address, not
On Tue, Oct 27, 2020 at 04:34:04PM -0600, Jordan Crouse wrote:
> This short series adds support for the adreno-smmu implementation of the
> arm-smmu driver and the device-tree bindings to turn on the implementation
> for the sm845 and sc7180 GPUs. These changes are the last ones needed to
>
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: 29 October 2020 15:54
> To: Shameerali Kolothum Thodi ;
> linux-arm-ker...@lists.infradead.org; iommu@lists.linux-foundation.org
> Cc: Linuxarm ; w...@kernel.org; j...@8bytes.org;
> jean-phili...@linaro.org;
From: Arnd Bergmann
> Sent: 29 October 2020 09:51
...
> I think ideally there would be no global variable, withall accesses
> encapsulated in function calls, possibly using static_call() optimizations
> if any of them are performance critical.
There isn't really a massive difference between
On Thu, Oct 29, 2020 at 03:05:31PM +, David Laight wrote:
> From: Arnd Bergmann
> > Sent: 28 October 2020 21:21
> >
> > From: Arnd Bergmann
> >
> > There are hundreds of warnings in a W=2 build about a local
> > variable shadowing the global 'apic' definition:
> >
> >
A common idiom for .of_xlate is to use of_find_device_by_node() to
retrieve the relevant IOMMU instance data when translating IOMMU
specifiers for a client device. Although it's slightly roundabout,
this is simply looking up something we know exists - if it *were*
to return NULL, that would mean
On 29/10/20 17:56, Arvind Sankar wrote:
>> For those two just add:
>> struct apic *apic = x86_system_apic;
>> before all the assignments.
>> Less churn and much better code.
>>
> Why would it be better code?
>
I think he means the compiler produces better code, because it won't
read the
With the introduction of def_domain_type in iommu_ops, vendor
drivers can now inform the iommu generic layer about any specific
default domain requirement for a device. Any pci dev marked as
untrusted is now prevented from having an IDENTITY mapping
domain.
The callback is also required when the
On Thu, Oct 29, 2020 at 03:34:48PM +, Robin Murphy wrote:
> A common idiom for .of_xlate is to use of_find_device_by_node() to
> retrieve the relevant IOMMU instance data when translating IOMMU
> specifiers for a client device. Although it's slightly roundabout,
> this is simply looking up
From: "Liu, Yi L"
In prq_event_thread(), the QI_PGRP_PDP is wrongly set by
'req->pasid_present' which should be replaced to
'req->priv_data_present'.
Fixes: 5b438f4ba315 ("iommu/vt-d: Support page request in scalable mode")
Signed-off-by: Liu, Yi L
Signed-off-by: Yi Sun
---
From: Liu Yi L
Should get correct sid and set it into sdev. Because we execute
'sdev->sid != req->rid' in the loop of prq_event_thread().
Fixes: eb8d93ea3c1d ("iommu/vt-d: Report page request faults for guest SVA")
Signed-off-by: Liu Yi L
Signed-off-by: Yi Sun
---
drivers/iommu/intel/svm.c |
We found a few issues about PRQ. So, two patches are cooked to
fix them. Please have a review. Thanks!
Changes from v1:
- Modify subject of patch 1 to make it more accurate.
- Move get_domain_info() up to the sanity check part in patch 1.
- Remove v1 patch 2 which is not
On Wed, Oct 28, 2020 at 7:51 AM Robin Murphy wrote:
> Hmm, perhaps I'm missing something here, but even if the config options
> *do* line up, what prevents arm-smmu probing before qcom-scm and
> dereferencing NULL in qcom_scm_qsmmu500_wait_safe_toggle() before __scm
> is initialised?
Oh man,
On 2020/10/29 21:51, Robin Murphy wrote:
On 2020-10-29 13:19, yukuai (C) wrote:
On 2020/10/29 18:08, Robin Murphy wrote:
On 2020-10-29 09:22, Yu Kuai wrote:
If of_find_device_by_node() failed in rk_iommu_of_xlate(), null pointer
dereference will be triggered. Thus return error code if
50 matches
Mail list logo
