When the dmar translation fault happens, the kernel prints a single line
fault reason with corresponding hexadecimal code defined in the Intel VT-d
specification.
Currently, when user wants to debug the translation fault in detail,
debugfs is used for dumping the dmar_translation_struct, which is
On Thu, Jul 15, 2021 at 08:12:00PM +0800, Yong Wu wrote:
> Add the binding for smi-sub-common. The SMI block diagram like this:
>
> IOMMU
> | |
> smi-common
> --
> | |
> larb0 larb7 <-max is 8
>
> The smi-common connects
On Thu, 15 Jul 2021 20:11:59 +0800, Yong Wu wrote:
> Add mt8195 smi supporting in the bindings.
>
> In mt8195, there are two smi-common HW, one is for vdo(video output),
> the other is for vpp(video processing pipe). They connect with different
> smi-larbs, then some setting(bus_sel) is
On Wed, Jul 21, 2021 at 1:23 PM Bjorn Andersson
wrote:
>
> On Wed 21 Jul 13:00 CDT 2021, Saravana Kannan wrote:
>
> > On Wed, Jul 21, 2021 at 10:24 AM John Stultz wrote:
> > >
> > > On Wed, Jul 21, 2021 at 4:54 AM Greg Kroah-Hartman
> > > wrote:
> > > >
> > > > On Wed, Jul 07, 2021 at
On Wed 21 Jul 13:00 CDT 2021, Saravana Kannan wrote:
> On Wed, Jul 21, 2021 at 10:24 AM John Stultz wrote:
> >
> > On Wed, Jul 21, 2021 at 4:54 AM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Wed, Jul 07, 2021 at 04:53:20AM +, John Stultz wrote:
> > > > Allow the qcom_scm driver to be
On Mon 19 Jul 16:53 CDT 2021, Saravana Kannan wrote:
> On Mon, Jul 19, 2021 at 12:36 PM Bjorn Andersson
> wrote:
> >
> > On Mon 19 Jul 14:00 CDT 2021, John Stultz wrote:
> >
> > > On Fri, Jul 16, 2021 at 10:01 PM Bjorn Andersson
> > > wrote:
> > > > On Tue 06 Jul 23:53 CDT 2021, John Stultz
> Fine with. I've queued up the modified patch.
Good. Thanks!
>
> On Sat, Jul 17, 2021 at 11:39:21AM +0300, Roman Skakun wrote:
> > > We can merge this patch and create a new one for
> > > xen_swiotlb_free_coherent() later.
> > > Yeah, no worries, I didn't know that exposing
To make io-pgtable aware of a flush queue being dynamically enabled,
allow IO_PGTABLE_QUIRK_NON_STRICT to be set even after a domain has been
attached to, and hook up the final piece of the puzzle in iommu-dma.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 15
Allocating and enabling a flush queue is in fact something we can
reasonably do while a DMA domain is active, without having to rebuild it
from scratch. Thus we can allow a strict -> non-strict transition from
sysfs without requiring to unbind the device's driver, which is of
particular interest
Factor out flush queue setup from the initial domain init so that we
can potentially trigger it from sysfs later on in a domain's lifetime.
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 31 ---
include/linux/dma-iommu.h | 9 ++---
2 files changed,
To parallel the sysfs behaviour, extend the build-time configuration
for default domains to include the new type as well.
Signed-off-by: Robin Murphy
---
This effectively replaces patch #3 of John's "iommu: Enhance IOMMU
default DMA mode build options" series.
---
drivers/iommu/Kconfig | 48
The sysfs interface for default domain types exists primarily so users
can choose the performance/security tradeoff relevant to their own
workload. As such, the choice between the policies for DMA domains fits
perfectly as an additional point on that scale - downgrading a
particular device from a
Eliminate the iommu_get_dma_strict() indirection and pipe the
information through the domain type from the beginning. Besides
the flow simplification this also has several nice side-effects:
- Automatically implies strict mode for untrusted devices by
virtue of their IOMMU_DOMAIN_DMA
In preparation for the strict vs. non-strict decision for DMA domains to
be expressed in the domain type, make sure we expose our flush queue
awareness by accepting the new domain type, and test the specific
feature flag where we want to identify DMA domains in general. The DMA
ops setup can
In preparation for the strict vs. non-strict decision for DMA domains to
be expressed in the domain type, make sure we expose our flush queue
awareness by accepting the new domain type, and test the specific
feature flag where we want to identify DMA domains in general.
Signed-off-by: Robin
The DMA ops setup can simply be unconditional, since iommu-dma
already knows not to touch identity domains.
Signed-off-by: Robin Murphy
---
drivers/iommu/amd/iommu.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/amd/iommu.c
Promote the difference between strict and non-strict DMA domains from an
internal detail to a distinct domain feature and type, to pave the road
for exposing it through the sysfs default domain interface.
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 2 +-
drivers/iommu/iommu.c
iommu_dma_init_domain() is now only called from iommu_setup_dma_ops(),
which has already assumed dev to be non-NULL.
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/virtio-iommu.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 6abdcab7273b..80930ce04a16 100644
--- a/drivers/iommu/virtio-iommu.c
IOVA cookies are now got and put by core code, so we no longer need to
export these to modular drivers. The export for getting MSI cookies
stays, since VFIO can still be a module, but it was already relying on
someone else putting them, so that aspect is unaffected.
Signed-off-by: Robin Murphy
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/sun50i-iommu.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/iommu/sun50i-iommu.c b/drivers/iommu/sun50i-iommu.c
index 181bb1c3437c..c349a95ec7bd 100644
---
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/sprd-iommu.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/iommu/sprd-iommu.c b/drivers/iommu/sprd-iommu.c
index 73dfd9946312..2bc1de6e823d 100644
--- a/drivers/iommu/sprd-iommu.c
+++
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/rockchip-iommu.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index 9febfb7f3025..c24561f54f32 100644
---
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/mtk_iommu.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 6f7c69688ce2..e39a6d1da28d 100644
--- a/drivers/iommu/mtk_iommu.c
+++
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/ipmmu-vmsa.c | 27 ---
1 file changed, 4 insertions(+), 23 deletions(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 51ea6f00db2f..31252268f0d0 100644
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/exynos-iommu.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index d0fbf1d10e18..34085d069cda 100644
---
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/intel/iommu.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index dd22fc7d5176..e2add5a0caef 100644
--- a/drivers/iommu/intel/iommu.c
+++
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 7 ---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 10 +++---
drivers/iommu/arm/arm-smmu/qcom_iommu.c | 8
3 files changed, 3 insertions(+), 22
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/amd/iommu.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 811a49a95d04..40ae7130fc80 100644
--- a/drivers/iommu/amd/iommu.c
+++
Now that everyone has converged on iommu-dma for IOMMU_DOMAIN_DMA
support, we can abandon the notion of drivers being responsible for the
cookie type, and consolidate all the management into the core code.
Signed-off-by: Robin Murphy
---
drivers/iommu/iommu.c | 7 +++
include/linux/iommu.h
Hi all,
First off, yes, this conflicts with just about everything else
currently in-flight. Sorry about that. If it stands up to initial review
then I'll start giving some thought to how to fit everything together
(particularly John's cleanup of strictness defaults, which I'd be
inclined to fold
On Wed, Jul 21, 2021 at 10:24 AM John Stultz wrote:
>
> On Wed, Jul 21, 2021 at 4:54 AM Greg Kroah-Hartman
> wrote:
> >
> > On Wed, Jul 07, 2021 at 04:53:20AM +, John Stultz wrote:
> > > Allow the qcom_scm driver to be loadable as a permenent module.
> >
> > This feels like a regression, it
On Wed, Jul 21, 2021 at 4:54 AM Greg Kroah-Hartman
wrote:
>
> On Wed, Jul 07, 2021 at 04:53:20AM +, John Stultz wrote:
> > Allow the qcom_scm driver to be loadable as a permenent module.
>
> This feels like a regression, it should be allowed to be a module.
I'm sorry, I'm not sure I'm
On 7/21/2021 10:33 PM, Christoph Hellwig wrote:
On Wed, Jul 21, 2021 at 06:28:48PM +0800, Tianyu Lan wrote:
dma_mmap_attrs() and dma_get_sgtable_attrs() get input virtual address
belonging to backing memory with struct page and returns bounce buffer
dma physical address which is below
On Wed, 21 Jul 2021 14:59:47 +0100,
Robin Murphy wrote:
>
> On 2021-07-21 14:12, Marc Zyngier wrote:
> > On Wed, 21 Jul 2021 12:42:14 +0100,
> > Robin Murphy wrote:
> >>
> >> [ +Marc for MSI bits ]
> >>
> >> On 2021-07-21 02:33, Bixuan Cui wrote:
> >>> Add suspend and resume support for
On Wed, Jul 21, 2021 at 06:28:48PM +0800, Tianyu Lan wrote:
> dma_mmap_attrs() and dma_get_sgtable_attrs() get input virtual address
> belonging to backing memory with struct page and returns bounce buffer
> dma physical address which is below shared_gpa_boundary(vTOM) and passed
> to Hyper-V via
On 2021/7/21 19:12, Robin Murphy wrote:
On 2021-07-21 02:50, Lu Baolu wrote:
Hi Robin,
Thanks a lot for reviewing my patch!
On 7/20/21 5:27 PM, Robin Murphy wrote:
On 2021-07-20 02:38, Lu Baolu wrote:
When the device and CPU share an address space (such as SVA), the
device
must support the
On 2021-07-21 14:12, Marc Zyngier wrote:
On Wed, 21 Jul 2021 12:42:14 +0100,
Robin Murphy wrote:
[ +Marc for MSI bits ]
On 2021-07-21 02:33, Bixuan Cui wrote:
Add suspend and resume support for arm-smmu-v3 by low-power mode.
When the smmu is suspended, it is powered off and the registers
On Tue, Jul 20, 2021 at 07:05:50PM -0500, Suthikulpanit, Suravee wrote:
> Hi Lennert,
Hi Suravee,
> > On an AMD system, I/O page faults are usually logged like this:
> >
> > diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> > index 811a49a95d04..7ae426b092f2 100644
> >
For the printing of RMP_HW_ERROR / RMP_PAGE_FAULT / IO_PAGE_FAULT
events, the AMD IOMMU code uses such logic:
if (pdev)
dev_data = dev_iommu_priv_get(>dev);
if (dev_data && __ratelimit(_data->rs)) {
pci_err(pdev, ...
} else {
On Thu, Jul 15, 2021 at 8:23 PM Yong Wu wrote:
>
> To improve the performance, We add some initial setting for smi larbs.
> there are two part:
> 1), Each port has the special ostd(outstanding) value in each larb.
> 2), Two general setting for each larb.
>
> In some SoC, this setting maybe
On Wed, 21 Jul 2021 12:42:14 +0100,
Robin Murphy wrote:
>
> [ +Marc for MSI bits ]
>
> On 2021-07-21 02:33, Bixuan Cui wrote:
> > Add suspend and resume support for arm-smmu-v3 by low-power mode.
> >
> > When the smmu is suspended, it is powered off and the registers are
> > cleared. So saves
On Thu, Jul 15, 2021 at 8:25 PM Yong Wu wrote:
>
> To improve the performance, add initial setting for smi-common.
> some register use some fix setting(suggested from DE).
>
> Signed-off-by: Yong Wu
> ---
> drivers/memory/mtk-smi.c | 42
> 1 file
On Thu, Jul 15, 2021 at 8:22 PM Yong Wu wrote:
>
> MT8195 has two smi-common, their IP are the same. Only the larbs that
> connect with the smi-common are different. thus the bus_sel are different
> for the two smi-common.
>
> Signed-off-by: Yong Wu
Reviewed-by: Ikjoon Jang
> ---
>
On Wed, Jul 21, 2021 at 12:07:22PM +0100, John Garry wrote:
> On 21/07/2021 10:59, Ming Lei wrote:
> > > I have now removed that from the tree, so please re-pull.
> > Now the kernel can be built successfully, but not see obvious improvement
> > on the reported issue:
> >
> >
On Wed, Jul 07, 2021 at 04:53:20AM +, John Stultz wrote:
> Allow the qcom_scm driver to be loadable as a permenent module.
This feels like a regression, it should be allowed to be a module.
> This still uses the "depends on QCOM_SCM || !QCOM_SCM" bit to
> ensure that drivers that call into
On Thu, Jul 15, 2021 at 8:24 PM Yong Wu wrote:
>
> No functional change. Simplify probing code.
>
> Signed-off-by: Yong Wu
Reviewed-by: Ikjoon Jang
> ---
> drivers/memory/mtk-smi.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/memory/mtk-smi.c
On Thu, Jul 15, 2021 at 8:25 PM Yong Wu wrote:
>
> In mt8195, there are some larbs connect with the smi-sub-common, then
> connect with smi-common.
Not critical but I suggest to describe what is smi-sub-common.
e.g. "some larbs are not directly connected to smi-common,
they are connected to
[ +Marc for MSI bits ]
On 2021-07-21 02:33, Bixuan Cui wrote:
Add suspend and resume support for arm-smmu-v3 by low-power mode.
When the smmu is suspended, it is powered off and the registers are
cleared. So saves the msi_msg context during msi interrupt initialization
of smmu. When resume
On 2021-07-21 02:50, Lu Baolu wrote:
Hi Robin,
Thanks a lot for reviewing my patch!
On 7/20/21 5:27 PM, Robin Murphy wrote:
On 2021-07-20 02:38, Lu Baolu wrote:
When the device and CPU share an address space (such as SVA), the device
must support the same addressing capability as the CPU.
On 21/07/2021 10:59, Ming Lei wrote:
I have now removed that from the tree, so please re-pull.
Now the kernel can be built successfully, but not see obvious improvement
on the reported issue:
[root@ampere-mtjade-04 ~]# uname -a
Linux ampere-mtjade-04.khw4.lab.eng.bos.redhat.com
Hi,
On Thu, Jul 15, 2021 at 8:23 PM Yong Wu wrote:
>
> No functional change. Only move the code position to make the code more
> readable.
> 1. Put the register smi-common above smi-larb. Prepare to add some others
>register setting.
> 2. Put mtk_smi_larb_unbind around larb_bind.
> 3. Sort
On Thu, Jul 15, 2021 at 8:23 PM Yong Wu wrote:
>
> Add error handle while component_add fail.
>
> Signed-off-by: Yong Wu
Reviewed-by: Ikjoon Jang
> ---
> It don't have the error handle when v1. it is not a fatal error.
> thus don't add fix tags.
> ---
> drivers/memory/mtk-smi.c | 10
On Thu, Jul 15, 2021 at 8:14 PM Yong Wu wrote:
>
> Prepare for adding smi sub common. Only rename from smi_gen to smi_type.
> No functional change.
>
> About the current "smi_gen", we have gen1/gen2 that stand for the
> generation number for HW. I plan to add a new type(sub_common), then the
>
On Thu, Jul 15, 2021 at 8:23 PM Yong Wu wrote:
>
> Use clk_bulk interface instead of the orginal one to simplify the code.
>
> SMI have several clocks: apb/smi/gals, the apb/smi clocks are required
> for both smi-common and smi-larb while the gals clock are optional.
> thus, use devm_clk_bulk_get
Thanks for review.
On 7/20/2021 9:54 PM, Christoph Hellwig wrote:
Please split the swiotlb changes into a separate patch from the
consumer.
OK. Will update.
}
+
+/*
+ * hv_map_memory - map memory to extra space in the AMD SEV-SNP Isolation VM.
+ */
+unsigned long hv_map_memory(unsigned
On Wed, Jul 21, 2021 at 10:23:38AM +0100, John Garry wrote:
> On 21/07/2021 02:40, Ming Lei wrote:
> > > I think that you should see a significant performance boost.
> > There is build issue, please check your tree:
> >
> >MODPOST vmlinux.symvers
> >MODINFO modules.builtin.modinfo
> >
On 21/07/2021 02:40, Ming Lei wrote:
I think that you should see a significant performance boost.
There is build issue, please check your tree:
MODPOST vmlinux.symvers
MODINFO modules.builtin.modinfo
GEN modules.builtin
LD .tmp_vmlinux.btf
ld: Unexpected GOT/PLT entries
Hi Jean,
> -Original Message-
> From: Jean-Philippe Brucker [mailto:jean-phili...@linaro.org]
> Sent: 04 March 2021 17:11
> To: Shameerali Kolothum Thodi
> Cc: linux-arm-ker...@lists.infradead.org; iommu@lists.linux-foundation.org;
> kvm...@lists.cs.columbia.edu; m...@kernel.org;
>
59 matches
Mail list logo
