Re: [PATCH v2 2/2] iommu/vt-d: skip invalid RMRR entries
Hi,
On 1/8/20 3:16 AM, Barret Rhoden via iommu wrote:
The VT-d docs specify requirements for the RMRR entries base and end
(called 'Limit' in the docs) addresses.
This commit will cause the DMAR processing to skip any RMRR entries that
do not meet these requirements and mark the firmware as tainted, since
the firmware is giving us junk.
Signed-off-by: Barret Rhoden
---
drivers/iommu/intel-iommu.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index a8bb458845bc..32c3c6338a3d 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4315,13 +4315,25 @@ static void __init init_iommu_pm_ops(void)
static inline void init_iommu_pm_ops(void) {}
#endif/* CONFIG_PM */
+static int rmrr_validity_check(struct acpi_dmar_reserved_memory *rmrr)
+{
+ if ((rmrr->base_address & PAGE_MASK) ||
+ (rmrr->end_address <= rmrr->base_address) ||
+ ((rmrr->end_address - rmrr->base_address + 1) & PAGE_MASK)) {
+ pr_err(FW_BUG "Broken RMRR base: %#018Lx end: %#018Lx\n",
+ rmrr->base_address, rmrr->end_address);
Since you will WARN_TAINT below, do you still want an error message
here?
+ return -EINVAL;
+ }
+ return 0;
+}
+
int __init dmar_parse_one_rmrr(struct acpi_dmar_header *header, void *arg)
{
struct acpi_dmar_reserved_memory *rmrr;
struct dmar_rmrr_unit *rmrru;
rmrr = (struct acpi_dmar_reserved_memory *)header;
- if (arch_rmrr_sanity_check(rmrr)) {
+ if (rmrr_validity_check(rmrr) || arch_rmrr_sanity_check(rmrr)) {
WARN_TAINT(1, TAINT_FIRMWARE_WORKAROUND,
"Your BIOS is broken; bad RMRR [%#018Lx-%#018Lx]\n"
"BIOS vendor: %s; Ver: %s; Product Version: %s\n",
Best regards,
baolu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [rfc] dma-mapping: preallocate unencrypted DMA atomic pool
On Tue, 7 Jan 2020, Christoph Hellwig wrote: > > On 01/01/2020 1:54 am, David Rientjes via iommu wrote: > >> Christoph, Thomas, is something like this (without the diagnosic > >> information included in this patch) acceptable for these allocations? > >> Adding expansion support when the pool is half depleted wouldn't be *that* > >> hard. > >> > >> Or are there alternatives we should consider? Thanks! > > > > Are there any platforms which require both non-cacheable remapping *and* > > unencrypted remapping for distinct subsets of devices? > > > > If not (and I'm assuming there aren't, because otherwise this patch is > > incomplete in covering only 2 of the 3 possible combinations), then > > couldn't we keep things simpler by just attributing both properties to the > > single "atomic pool" on the basis that one or the other will always be a > > no-op? In other words, basically just tweaking the existing "!coherent" > > tests to "!coherent || force_dma_unencrypted()" and doing > > set_dma_unencrypted() unconditionally in atomic_pool_init(). > > I think that would make most sense. > I'll rely on Thomas to chime in if this doesn't make sense for the SEV usecase. I think the sizing of the single atomic pool needs to be determined. Our peak usage that we have measured from NVMe is ~1.4MB and atomic_pool is currently sized to 256KB by default. I'm unsure at this time if we need to be able to dynamically expand this pool with a kworker. Maybe when CONFIG_AMD_MEM_ENCRYPT is enabled this atomic pool should be sized to 2MB or so and then when it reaches half capacity we schedule some background work to dynamically increase it? That wouldn't be hard unless the pool can be rapidly depleted. Do we want to increase the atomic pool size by default and then do background dynamic expansion? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 1/2] iommu/vt-d: skip RMRR entries that fail the sanity check
RMRR entries describe memory regions that are DMA targets for devices
outside the kernel's control.
RMRR entries that fail the sanity check are pointing to regions of
memory that the firmware did not tell the kernel are reserved or
otherwise should not be used.
Instead of aborting DMAR processing, this commit skips these RMRR
entries and marks the firmware as tainted. They will not be mapped into
the IOMMU, but the IOMMU can still be utilized. If anything, when the
IOMMU is on, those devices will not be able to clobber RAM that the
kernel has allocated from those regions.
Signed-off-by: Barret Rhoden
---
drivers/iommu/intel-iommu.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 0c8d81f56a30..a8bb458845bc 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4319,12 +4319,18 @@ int __init dmar_parse_one_rmrr(struct acpi_dmar_header
*header, void *arg)
{
struct acpi_dmar_reserved_memory *rmrr;
struct dmar_rmrr_unit *rmrru;
- int ret;
rmrr = (struct acpi_dmar_reserved_memory *)header;
- ret = arch_rmrr_sanity_check(rmrr);
- if (ret)
- return ret;
+ if (arch_rmrr_sanity_check(rmrr)) {
+ WARN_TAINT(1, TAINT_FIRMWARE_WORKAROUND,
+ "Your BIOS is broken; bad RMRR [%#018Lx-%#018Lx]\n"
+ "BIOS vendor: %s; Ver: %s; Product Version: %s\n",
+ rmrr->base_address, rmrr->end_address,
+ dmi_get_system_info(DMI_BIOS_VENDOR),
+ dmi_get_system_info(DMI_BIOS_VERSION),
+ dmi_get_system_info(DMI_PRODUCT_VERSION));
+ return 0;
+ }
rmrru = kzalloc(sizeof(*rmrru), GFP_KERNEL);
if (!rmrru)
--
2.24.1.735.g03f4e72817-goog
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 2/2] iommu/vt-d: skip invalid RMRR entries
The VT-d docs specify requirements for the RMRR entries base and end
(called 'Limit' in the docs) addresses.
This commit will cause the DMAR processing to skip any RMRR entries that
do not meet these requirements and mark the firmware as tainted, since
the firmware is giving us junk.
Signed-off-by: Barret Rhoden
---
drivers/iommu/intel-iommu.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index a8bb458845bc..32c3c6338a3d 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4315,13 +4315,25 @@ static void __init init_iommu_pm_ops(void)
static inline void init_iommu_pm_ops(void) {}
#endif /* CONFIG_PM */
+static int rmrr_validity_check(struct acpi_dmar_reserved_memory *rmrr)
+{
+ if ((rmrr->base_address & PAGE_MASK) ||
+ (rmrr->end_address <= rmrr->base_address) ||
+ ((rmrr->end_address - rmrr->base_address + 1) & PAGE_MASK)) {
+ pr_err(FW_BUG "Broken RMRR base: %#018Lx end: %#018Lx\n",
+ rmrr->base_address, rmrr->end_address);
+ return -EINVAL;
+ }
+ return 0;
+}
+
int __init dmar_parse_one_rmrr(struct acpi_dmar_header *header, void *arg)
{
struct acpi_dmar_reserved_memory *rmrr;
struct dmar_rmrr_unit *rmrru;
rmrr = (struct acpi_dmar_reserved_memory *)header;
- if (arch_rmrr_sanity_check(rmrr)) {
+ if (rmrr_validity_check(rmrr) || arch_rmrr_sanity_check(rmrr)) {
WARN_TAINT(1, TAINT_FIRMWARE_WORKAROUND,
"Your BIOS is broken; bad RMRR [%#018Lx-%#018Lx]\n"
"BIOS vendor: %s; Ver: %s; Product Version: %s\n",
--
2.24.1.735.g03f4e72817-goog
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 0/2] iommu/vt-d bad RMRR workarounds
Commit f036c7fa0ab6 ("iommu/vt-d: Check VT-d RMRR region in BIOS is
reported as reserved") caused a machine to fail to boot for me, but only
after a kexec.
Buggy firmware provided an RMRR entry with base and end both == 0. That
is an invalid RMRR format, and only happens to pass the RMRR sanity
check. After a kexec, that entry fails the RMRR sanity check, due to a
slight change in the first e820 mapping. See the v1 link for details.
v1->v2:
v1: https://lore.kernel.org/lkml/20191211194606.87940-1-b...@google.com/
- Added the TAINT_FIRMWARE_WORKAROUND
- Dropped the commit that treated missing e820 regions as "RMRR OK"
Barret Rhoden (2):
iommu/vt-d: skip RMRR entries that fail the sanity check
iommu/vt-d: skip invalid RMRR entries
drivers/iommu/intel-iommu.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
--
2.24.1.735.g03f4e72817-goog
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: dma-direct: don't check swiotlb=force in dma_direct_map_resource
On Tue, Jan 07, 2020 at 06:18:28PM +, Robin Murphy wrote:
> On 07/01/2020 5:38 pm, Naresh Kamboju wrote:
> > Following build error on stable-rc 5.4.9-rc1 for arm architecture.
> >
> > dma/direct.c: In function 'dma_direct_possible':
> > dma/direct.c:329:3: error: too many arguments to function 'dma_capable'
> > dma_capable(dev, dma_addr, size, true);
> > ^~~
>
> Not sure that $SUBJECT comes into it at all, but by the look of it I guess
> "dma-direct: exclude dma_direct_map_resource from the min_low_pfn check"
> implicitly depends on 130c1ccbf553 ("dma-direct: unify the dma_capable
> definitions") too.
Ugh, good catch. I'll drop these patches, they don't look ok for stable
at this point in time.
thanks,
greg k-h
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: dma-direct: don't check swiotlb=force in dma_direct_map_resource
On 07/01/2020 5:38 pm, Naresh Kamboju wrote:
Following build error on stable-rc 5.4.9-rc1 for arm architecture.
dma/direct.c: In function 'dma_direct_possible':
dma/direct.c:329:3: error: too many arguments to function 'dma_capable'
dma_capable(dev, dma_addr, size, true);
^~~
Not sure that $SUBJECT comes into it at all, but by the look of it I
guess "dma-direct: exclude dma_direct_map_resource from the min_low_pfn
check" implicitly depends on 130c1ccbf553 ("dma-direct: unify the
dma_capable definitions") too.
Robin.
In file included from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/include/linux/dma-direct.h:12:0,
from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/kernel/dma/direct.c:10:
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/arch/arm/include/asm/dma-direct.h:17:20:
note: declared here
static inline bool dma_capable(struct device *dev, dma_addr_t addr,
size_t size)
^~~
In file included from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/include/linux/init.h:5:0,
from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/include/linux/memblock.h:12,
from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/kernel/dma/direct.c:7:
dma/direct.c: In function 'dma_direct_map_resource':
dma/direct.c:378:16: error: too many arguments to function 'dma_capable'
if (unlikely(!dma_capable(dev, dma_addr, size, false))) {
^
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/include/linux/compiler.h:78:42:
note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
^
In file included from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/include/linux/dma-direct.h:12:0,
from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/kernel/dma/direct.c:10:
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/arch/arm/include/asm/dma-direct.h:17:20:
note: declared here
static inline bool dma_capable(struct device *dev, dma_addr_t addr,
size_t size)
^~~
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/scripts/Makefile.build:265:
recipe for target 'kernel/dma/direct.o' failed
Full build log link,
https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-stable-rc-5.4/DISTRO=lkft,MACHINE=am57xx-evm,label=docker-lkft/44/consoleText
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: dma-direct: don't check swiotlb=force in dma_direct_map_resource
Following build error on stable-rc 5.4.9-rc1 for arm architecture.
dma/direct.c: In function 'dma_direct_possible':
dma/direct.c:329:3: error: too many arguments to function 'dma_capable'
dma_capable(dev, dma_addr, size, true);
^~~
In file included from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/include/linux/dma-direct.h:12:0,
from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/kernel/dma/direct.c:10:
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/arch/arm/include/asm/dma-direct.h:17:20:
note: declared here
static inline bool dma_capable(struct device *dev, dma_addr_t addr,
size_t size)
^~~
In file included from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/include/linux/init.h:5:0,
from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/include/linux/memblock.h:12,
from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/kernel/dma/direct.c:7:
dma/direct.c: In function 'dma_direct_map_resource':
dma/direct.c:378:16: error: too many arguments to function 'dma_capable'
if (unlikely(!dma_capable(dev, dma_addr, size, false))) {
^
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/include/linux/compiler.h:78:42:
note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
^
In file included from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/include/linux/dma-direct.h:12:0,
from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/kernel/dma/direct.c:10:
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/arch/arm/include/asm/dma-direct.h:17:20:
note: declared here
static inline bool dma_capable(struct device *dev, dma_addr_t addr,
size_t size)
^~~
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/scripts/Makefile.build:265:
recipe for target 'kernel/dma/direct.o' failed
Full build log link,
https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-stable-rc-5.4/DISTRO=lkft,MACHINE=am57xx-evm,label=docker-lkft/44/consoleText
--
Linaro LKFT
https://lkft.linaro.org
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/dma: fix variable 'cookie' set but not used
On Mon, Jan 06, 2020 at 10:27:27AM -0500, Qian Cai wrote:
> The commit c18647900ec8 ("iommu/dma: Relax locking in
> iommu_dma_prepare_msi()") introduced a compliation warning,
>
> drivers/iommu/dma-iommu.c: In function 'iommu_dma_prepare_msi':
> drivers/iommu/dma-iommu.c:1206:27: warning: variable 'cookie' set but
> not used [-Wunused-but-set-variable]
> struct iommu_dma_cookie *cookie;
>^~
>
> Fixes: c18647900ec8 ("iommu/dma: Relax locking in iommu_dma_prepare_msi()")
> Signed-off-by: Qian Cai
> ---
> drivers/iommu/dma-iommu.c | 3 ---
> 1 file changed, 3 deletions(-)
Applied for v5.5, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/qcom: fix NULL pointer dereference during probe deferral
On Tue, Jan 07, 2020 at 09:00:14AM -0500, Brian Masney wrote: > On Tue, Jan 07, 2020 at 02:25:30PM +0100, Joerg Roedel wrote: > > On Tue, Dec 31, 2019 at 10:39:49PM -0500, Brian Masney wrote: > > > drivers/iommu/qcom_iommu.c | 12 ++-- > > > 1 file changed, 10 insertions(+), 2 deletions(-) > > > > Shortened commit-message a bit and applied for v5.5, thanks. > > You might want to hold off on applying this since it looks like Robin > Murphy has a better fix. > > https://lore.kernel.org/lkml/fc055443-8716-4a0e-b4d5-311517d71...@arm.com/ Alright, thanks for the heads-up. I dropped that patch from my fixes branch. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/qcom: fix NULL pointer dereference during probe deferral
On Tue, Jan 07, 2020 at 02:25:30PM +0100, Joerg Roedel wrote: > On Tue, Dec 31, 2019 at 10:39:49PM -0500, Brian Masney wrote: > > drivers/iommu/qcom_iommu.c | 12 ++-- > > 1 file changed, 10 insertions(+), 2 deletions(-) > > Shortened commit-message a bit and applied for v5.5, thanks. You might want to hold off on applying this since it looks like Robin Murphy has a better fix. https://lore.kernel.org/lkml/fc055443-8716-4a0e-b4d5-311517d71...@arm.com/ Brian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 0/5] Clean up VMD DMA Map Ops
On Tue, Dec 31, 2019 at 01:24:18PM -0700, Jon Derrick wrote: > Jon Derrick (5): > iommu: Remove device link to group on failure > iommu/vt-d: Unlink device if failed to add to group Added 'Fixes:' tags to these two and applied them for v5.5, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] iommu/vt-d: Add a quirk flag for scope mismatched devices
WTF is a NVMe host supposed to mean for a PCIe device. NVMe defines the host as following: "1.6.16 host An entity that interfaces to an NVM subsystem through one or more controllers and submits commands to Submission Queues and retrieves command completions from Completion Queues." in other words - the Linux kernel is the NVMe host. You need to describe this magic broken piece of crap a lot better than that. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/qcom: fix NULL pointer dereference during probe deferral
On Tue, Dec 31, 2019 at 10:39:49PM -0500, Brian Masney wrote: > drivers/iommu/qcom_iommu.c | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) Shortened commit-message a bit and applied for v5.5, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] iommu/amd: Fix typos for PPR macros
On Mon, Dec 30, 2019 at 01:56:54PM +0800, Adrian Huang wrote: > From: Adrian Huang > > The bit 13 and bit 14 of the IOMMU control register are > PPRLogEn and PPRIntEn. They are related to PPR (Peripheral Page > Request) instead of 'PPF'. Fix them accrodingly. > > Signed-off-by: Adrian Huang > --- > drivers/iommu/amd_iommu_init.c | 4 ++-- > drivers/iommu/amd_iommu_types.h | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] iommu/amd: Remove local variables
On Tue, Dec 24, 2019 at 10:46:47PM +0800, Adrian Huang wrote:
> From: Adrian Huang
>
> The usage of the local variables 'range' and 'misc' was removed
> from commit 226e889b20a9 ("iommu/amd: Remove first/last_device handling")
> and commit 23c742db2171 ("iommu/amd: Split out PCI related parts of
> IOMMU initialization"). So, remove them accrodingly.
>
> Signed-off-by: Adrian Huang
> ---
> drivers/iommu/amd_iommu_init.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PULL REQUEST] iommu/vt-d: patches for v5.6
On Thu, Jan 02, 2020 at 08:18:01AM +0800, Lu Baolu wrote: > Hi Joerg, > > Below patches have been piled up for v5.6. > > - Some preparation patches for VT-d nested mode support >- VT-d Native Shared virtual memory cleanup and fixes >- Use 1st-level for IOVA translation > > - VT-d debugging and tracing >- Extend map_sg trace event for more information >- Add debugfs support to show page table internals > > - Kconfig option for the default status of scalable mode > > - Some miscellaneous cleanups. > > Please consider them for the iommu/vt-d branch. Applied patches 1-21 to the x86/vt-d branch, thanks Baolu. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/vt-d fix adding non-PCI devices to Intel IOMMU
On Fri, Dec 27, 2019 at 12:56:18AM +0100, Patrick Steinhardt wrote: > > I've recently spotted above warning in v5.5-rc3. The attached fix > is rather intended as a discussion starter -- it's quite likely > to be wrong as I ain't got much of a clue about the IOMMU > subsystem. > > drivers/iommu/intel-iommu.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) Applied for v5.5. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] iommu/qcom: fix NULL pointer dereference during probe deferral
On Mon, Jan 06, 2020 at 01:26:58PM +, Robin Murphy wrote: > On 04/01/2020 12:20 am, Brian Masney wrote: > > When attempting to load the qcom-iommu driver, and an -EPROBE_DEFER > > error occurs, the following attempted NULL pointer deference occurs: > > > > Unable to handle kernel NULL pointer dereference at virtual address > > 0014 > > pgd = (ptrval) > > [0014] *pgd= > > Internal error: Oops: 5 [#1] PREEMPT SMP ARM > > Modules linked in: > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted > > 5.5.0-rc2-next-20191220-00010-gfb6b8e8bced6-dirty #3 > > Hardware name: Generic DT based system > > PC is at qcom_iommu_domain_free (include/linux/pm_runtime.h:226 > >drivers/iommu/qcom_iommu.c:358) > > LR is at release_iommu_mapping (arch/arm/mm/dma-mapping.c:2141) > > pc : lr : psr: 6013 > > sp : ee89dc48 ip : fp : c13a6684 > > r10: c13a661c r9 : r8 : c13a1240 > > r7 : fdfb r6 : r5 : edc32f00 r4 : edc32f1c > > r3 : r2 : 0001 r1 : 0004 r0 : edc32f1c > > Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > > Control: 10c5787d Table: 0020406a DAC: 0051 > > Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) > > Stack: (0xee89dc48 to 0xee89e000) > > dc40: edc3d010 edc37020 c0316af8 edc3d010 > > edc37000 > > dc60: c0319684 c14341ac edc3d010 c083bd88 edc3d010 > > c13a1240 > > dc80: c083c2e8 c13a6684 c13a661c c13a6508 c13a661c c083c134 c13a1240 > > ee89dcec > > dca0: edc3d010 ee89dcec c083c2e8 c13a6684 c13a661c c13a6508 > > c13a661c > > dcc0: c13a6684 c083a31c c13a6684 ee82a86c edc327b8 c1304e48 edc3d010 > > 0001 > > dce0: edc3d054 c083bc08 ee82a880 edc3d010 0001 c1304e48 edc3d010 > > edc3d010 > > dd00: c13a69e8 c083b010 edc3d010 eea1fc10 c0837aac 0200 > > > > dd20: c1304e48 edc3d000 eea1fc10 > > > > dd40: eeff42f4 0001 c09e96e0 eeff42a4 > > > > dd60: eea1fc10 c09e98bc 0001 eea1fc10 > > eea1fc10 > > dd80: edc32c00 c1391580 eea1fc10 0001 eea1fc10 c0850f90 c2706dec > > c14368c0 > > dda0: 6013 c1304e48 0106 eeff42a4 eeff3fa0 > > eea1fc10 > > ddc0: 0001 c1248900 0106 c09e9bd0 0001 c0c2ee64 eea1fc00 > > eea1fc10 > > dde0: eea1fc10 c13a5b70 c1248900 c081496c c1023d84 > > > > de00: eeff3fa0 c2706e48 c2706e48 c1304e48 0001 eea1fc10 > > c13a5b70 > > de20: c13a5b70 c1248900 0106 c083dfb8 c14341ac > > eea1fc10 > > de40: c083be58 eea1fc10 c13a5b70 c13a5b70 c13a69e8 c12003ec > > c123a854 > > de60: c1248900 c083c134 c1248900 c09e6f3c c0d8d514 eea1fc10 > > c13a5b70 > > de80: c13a69e8 c12003ec c123a854 c1248900 0106 c083c3e0 > > c13a5b70 > > dea0: eea1fc10 c083c440 c13a5b70 c083c3e8 c083a23c 0106 > > ee82a858 > > dec0: eea052b4 c1304e48 c13a5b70 edc32b80 c083b270 c1043084 > > c121d1d8 > > dee0: e000 c13a5b70 c121d1d8 e000 c083cfcc c13ece60 > > c121d1d8 > > df00: e000 c0302f90 0106 c034407c c10e3a00 c1044dd0 > > c12003ec > > df20: 0006 0006 c0fbecac c0fada88 c0fada3c > > efffcbf8 > > df40: efffcc0d c1304e48 0006 c13f9500 c1304e48 c123a830 > > 0007 > > df60: c13f9500 c13f9500 c123a834 c1200f64 0006 0006 > > c12003ec > > df80: c0c28194 c0c28194 > > > > dfa0: c0c2819c c03010e8 > > > > dfc0: > > > > dfe0: 0013 > > > > (qcom_iommu_domain_free) from release_iommu_mapping > >(arch/arm/mm/dma-mapping.c:2141) > > (release_iommu_mapping) from arch_teardown_dma_ops > >(include/linux/dma-mapping.h:271 arch/arm/mm/dma-mapping.c:2335) > > (arch_teardown_dma_ops) from really_probe (drivers/base/dd.c:607) > > (really_probe) from driver_probe_device (drivers/base/dd.c:721) > > (driver_probe_device) from bus_for_each_drv (drivers/base/bus.c:431) > > (bus_for_each_drv) from __device_attach (drivers/base/dd.c:896) > > (__device_attach) from bus_probe_device (drivers/base/bus.c:491) > > (bus_probe_device) from device_add (drivers/base/core.c:2488) > > (device_add) from of_platform_device_create_pdata > >(drivers/of/platform.c:189) > > (of_platform_device_create_pdata) from of_platform_bus_create > >
Re: [PATCH v2 01/19] dt-bindings: mediatek: Add bindings for MT6779
On Mon, 2020-01-06 at 15:57 -0600, Rob Herring wrote: > On Sun, 5 Jan 2020 18:45:05 +0800, Chao Hao wrote: > > This patch adds description for MT6779 IOMMU. > > > > MT6779 has two iommus, they are MM_IOMMU and APU_IOMMU which > > use ARM Short-Descriptor translation format. > > > > The MT6779 IOMMU hardware diagram is as below, it is only a brief > > diagram about iommu, it don't focus on the part of smi_larb, so > > I don't describe the smi_larb detailedly. > > > > EMI > > | > >-- > >|| > > MM_IOMMUAPU_IOMMU > >|| > >SMI_COMMOM--- APU_BUS > > ||| > > SMI_LARB(0~11) SMI_LARB12(FAKE)SMI_LARB13(FAKE) > > ||| > > || -- > > || | | | > >Multimedia engine CCU VPU MDLA EMDA > > > > All the connections are hardware fixed, software can not adjust it. > > > > >From the diagram above, MM_IOMMU provides mapping for multimedia engine, > > but CCU is connected with smi_common directly, we can take them as larb12. > > APU_IOMMU provides mapping for APU engine, we can take them larb13. > > Larb12 and Larb13 are fake larbs. > > > > Signed-off-by: Chao Hao > > --- > > .../bindings/iommu/mediatek,iommu.txt | 2 + > > include/dt-bindings/memory/mt6779-larb-port.h | 215 ++ > > 2 files changed, 217 insertions(+) > > create mode 100644 include/dt-bindings/memory/mt6779-larb-port.h > > > > Please add Acked-by/Reviewed-by tags when posting new versions. However, > there's no need to repost patches *only* to add the tags. The upstream > maintainer will do that for acks received on the version they apply. > > If a tag was not added on purpose, please state why and what changed. Hi Rob, I am Sorry, this is my first time upstream and not clear for some details, please forgive me for this mistake. I put the changed explanation into cover letter([PATCH v2 00/19] MT6779 IOMMU SUPPORT) about this patch. I will pay attention to this problem in next version. Change since v1 for this patch 1.Delete M4U_PORT_UNKNOWN define because of not use it. 2.Correct coding format: ex: /*larb3-VENC*/ --> /* larb3-VENC */ ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [rfc] dma-mapping: preallocate unencrypted DMA atomic pool
On Mon, Jan 06, 2020 at 05:34:00PM +, Robin Murphy wrote: > On 01/01/2020 1:54 am, David Rientjes via iommu wrote: >> Christoph, Thomas, is something like this (without the diagnosic >> information included in this patch) acceptable for these allocations? >> Adding expansion support when the pool is half depleted wouldn't be *that* >> hard. >> >> Or are there alternatives we should consider? Thanks! > > Are there any platforms which require both non-cacheable remapping *and* > unencrypted remapping for distinct subsets of devices? > > If not (and I'm assuming there aren't, because otherwise this patch is > incomplete in covering only 2 of the 3 possible combinations), then > couldn't we keep things simpler by just attributing both properties to the > single "atomic pool" on the basis that one or the other will always be a > no-op? In other words, basically just tweaking the existing "!coherent" > tests to "!coherent || force_dma_unencrypted()" and doing > set_dma_unencrypted() unconditionally in atomic_pool_init(). I think that would make most sense. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
