Hi Christoph,
On 1/4/22 6:08 PM, Christoph Hellwig wrote:
On Tue, Jan 04, 2022 at 09:56:31AM +0800, Lu Baolu wrote:
Multiple devices may be placed in the same IOMMU group because they
cannot be isolated from each other. These devices must either be
entirely under kernel control or userspace
Hi Jason,
On 1/4/22 8:48 PM, Jason Gunthorpe wrote:
On Tue, Jan 04, 2022 at 09:56:30AM +0800, Lu Baolu wrote:
v5:
- Move kernel dma ownership auto-claiming from driver core to bus
callback. (Greg)
- Refactor the iommu interfaces to make them more specific.
(Jason/Robin)
-
On Tue, Jan 04, 2022 at 01:51:30PM -0600, Bjorn Helgaas wrote:
> On Tue, Jan 04, 2022 at 03:26:14PM -0400, Jason Gunthorpe wrote:
> > On Tue, Jan 04, 2022 at 11:06:31AM -0600, Bjorn Helgaas wrote:
> >
> > > > The existing vfio framework allows the portdrv driver to be bound
> > > > to the bridge
Hi Tom,
For larger TDX VM, memset() after set_memory_decrypted() in
swiotlb_update_mem_attributes() takes substantial portion of boot time.
It makes me wounder why do we need it there? Malicious VMM can mess with
decrypted/shared buffer at any point and for normal use it will be
populated with
On Sat, Dec 25, 2021 at 08:35:55PM +0100, David Heidelberg wrote:
> Convert Qualcomm IOMMU v0 implementation to yaml format.
>
> Signed-off-by: David Heidelberg
> ---
> v2:
> - fix wrong path in binding $id
> - comment qcom,mdp4 node example (we don't want to validate it yet)
>
>
On Tue, Jan 04, 2022 at 03:26:14PM -0400, Jason Gunthorpe wrote:
> On Tue, Jan 04, 2022 at 11:06:31AM -0600, Bjorn Helgaas wrote:
>
> > > The existing vfio framework allows the portdrv driver to be bound
> > > to the bridge while its downstream devices are assigned to user space.
> >
> > I.e.,
On Tue, Jan 04, 2022 at 11:06:31AM -0600, Bjorn Helgaas wrote:
> > The existing vfio framework allows the portdrv driver to be bound
> > to the bridge while its downstream devices are assigned to user space.
>
> I.e., the existing VFIO framework allows a switch to be in the same
> IOMMU group as
On Tue, Jan 04, 2022 at 10:41:00AM -0600, Bjorn Helgaas wrote:
> On Tue, Jan 04, 2022 at 02:08:00AM -0800, Christoph Hellwig wrote:
> > On Tue, Jan 04, 2022 at 09:56:31AM +0800, Lu Baolu wrote:
> > > Multiple devices may be placed in the same IOMMU group because they
> > > cannot be isolated from
On Tue, Jan 04, 2022 at 09:56:39AM +0800, Lu Baolu wrote:
> If a switch lacks ACS P2P Request Redirect, a device below the switch can
> bypass the IOMMU and DMA directly to other devices below the switch, so
> all the downstream devices must be in the same IOMMU group as the switch
> itself.
Help
On Tue, Jan 04, 2022 at 02:08:00AM -0800, Christoph Hellwig wrote:
> On Tue, Jan 04, 2022 at 09:56:31AM +0800, Lu Baolu wrote:
> > Multiple devices may be placed in the same IOMMU group because they
> > cannot be isolated from each other. These devices must either be
> > entirely under kernel
On Tue, Jan 04, 2022 at 04:03:07PM +0100, Christoph Hellwig wrote:
> On Tue, Jan 04, 2022 at 02:51:55PM +, Wei Liu wrote:
> > > Please stub out all of swiotlb_mem_remap instead of the ifdef inside the
> > > function.
> >
> > Does this look okay to you?
>
> Yes, thanks!
Thanks for
Il 23/09/21 13:58, Yong Wu ha scritto:
In prevous SoC, the sub common id occupy 2 bits. the mt8195's sub common
id has 3bits. Add a new flag for this. and rename the prevous flag to
_2BITS. For readable, I put these two flags together, then move the
other flags. no functional change.
Il 23/09/21 13:58, Yong Wu ha scritto:
In previous mt2712, Both IOMMUs are MM IOMMU, and they will share pgtable.
However in the latest SoC, another is infra IOMMU, there is no reason to
share pgtable between MM with INFRA IOMMU. This patch manage to
implement the two case(sharing and
Il 23/09/21 13:58, Yong Wu ha scritto:
Prepare for 2 HWs that sharing pgtable in different power-domains.
When there are 2 M4U HWs, it may has problem in the flush_range in which
we get the pm_status via the m4u dev, BUT that function don't reflect the
real power-domain status of the HW since
Il 23/09/21 13:58, Yong Wu ha scritto:
Currently the output PA[32:33] is contained by the flag IOVA_34.
This is not right. the iova_34 has no relation with pa[32:33], the 32bits
iova still could map to pa[32:33]. Move it out from the flag.
No need fix tag since currently only mt8192 use the
Il 23/09/21 13:58, Yong Wu ha scritto:
Lack the list_del in the mtk_iommu_remove, and remove
bus_set_iommu(*, NULL) since there may be several iommu HWs.
we can not bus_set_iommu null when one iommu driver unbind.
This issue is not so important, No need fix tags.
Signed-off-by: Yong Wu
I
Il 23/09/21 13:58, Yong Wu ha scritto:
The tlb_flush_all also touches the registers about tlb operations.
Add spinlock in it to protect the tlb registers. since the tlb_range
already hold the spinlock, move it a bit outside the spinlock to
print log.
Signed-off-by: Yong Wu
Reviewed-by:
Il 23/09/21 13:58, Yong Wu ha scritto:
The tlb_sync_all is called from these three functions:
a) flush_iotlb_all: it will be called for each a iommu HW.
b) tlb_flush_range_sync: it already has for_each_m4u.
c) in irq: When IOMMU HW translation fault, Only need flush itself.
Thus, No need
Il 23/09/21 13:58, Yong Wu ha scritto:
After the commit b34ea31fe013 ("iommu/mediatek: Always enable the clk on
resume"), the iommu clock is controlled by the runtime callback.
thus remove the clk control in the mtk_iommu_remove.
Otherwise, it will warning like:
echo 14018000.iommu >
Il 23/09/21 13:58, Yong Wu ha scritto:
To simplify the code, Remove the power status checking in the
tlb_flush_all, remove this:
if (pm_runtime_get_if_in_use(data->dev) <= 0)
continue;
After this patch, the mtk_iommu_tlb_flush_all will be called from
a) isr
b) pm runtime resume
Il 23/09/21 13:58, Yong Wu ha scritto:
For MM IOMMU, We always add device link between smi-common and IOMMU HW.
In mt8195, we add smi-sub-common. Thus, if the node is sub-common, we still
need find again to get smi-common, then do device link.
Signed-off-by: Yong Wu
Reviewed-by:
Il 23/09/21 13:58, Yong Wu ha scritto:
Prepare for supporting INFRA_IOMMU, and APU_IOMMU later.
For Infra IOMMU/APU IOMMU, it doesn't have the "larb""port". thus, Use
the MM flag contain the MM_IOMMU special flow, Also, it moves a big
chunk code about parsing the mediatek,larbs into a function,
Il 23/09/21 13:58, Yong Wu ha scritto:
Currently the code for of_iommu_configure_dev_id is like this:
static int of_iommu_configure_dev_id(struct device_node *master_np,
struct device *dev,
const u32 *id)
{
Il 23/09/21 13:58, Yong Wu ha scritto:
Allow the type IOMMU_DOMAIN_UNMANAGED since vfio_iommu_type1.c always call
iommu_domain_alloc. The PCIe EP works ok when going through vfio.
Signed-off-by: Yong Wu
Acked-by: AngeloGioacchino Del Regno
___
Il 23/09/21 13:58, Yong Wu ha scritto:
The infra iommu enable bits in mt8195 is in the pericfg register segment,
use regmap to update it.
If infra iommu master translation fault, It don't have the larbid/portid,
thus print out the whole register value.
Since regmap_update_bits may fail, add
Il 23/09/21 13:58, Yong Wu ha scritto:
In the infra iommu, we should disable DCM. add a new flag for this.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
___
iommu mailing list
iommu@lists.linux-foundation.org
Il 23/09/21 13:58, Yong Wu ha scritto:
Add a new flag NON_STD_AXI, All the previous SoC support this flag.
Prepare for adding infra and apu iommu which don't support this.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
___
iommu
Il 23/09/21 13:58, Yong Wu ha scritto:
The MediaTek IOMMU don't care about granule when tlb flushing.
Remove this variable.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
___
iommu mailing list
iommu@lists.linux-foundation.org
Il 23/09/21 13:58, Yong Wu ha scritto:
mt8195 has 3 IOMMU, containing 2 MM IOMMUs, one is for vdo, the other
is for vpp. and 1 INFRA IOMMU.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
___
iommu mailing list
Il 23/09/21 13:58, Yong Wu ha scritto:
Add IOMMU_TYPE definition. In the mt8195, we have another IOMMU_TYPE:
infra iommu, also there will be another APU_IOMMU, thus, use 2bits for the
IOMMU_TYPE.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
Il 23/09/21 13:58, Yong Wu ha scritto:
In mt8192, we preassign 0-4G; 4G-8G; 8G-12G for different multimedia
engines. This depends on the "dma-ranges=" in the iommu consumer's dtsi
node.
Adds 12G-16G region here. and reword the previous comment. we don't limit
which master locate in which
Il 23/09/21 13:58, Yong Wu ha scritto:
No functional change. Use "base" instead of the data->base. This is
avoid to touch too many lines in the next patches.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
___
iommu mailing list
Il 23/09/21 13:58, Yong Wu ha scritto:
The mt8195 IOMMU HW max support 5 banks, and regarding the banks'
registers, it looks like:
|bank0 | bank1 | bank2 | bank3 | bank4|
|global |
|control|
Il 23/09/21 13:58, Yong Wu ha scritto:
No functional change too, prepare for mt8195 IOMMU support bank functions.
Some global control settings are in bank0 while the other banks have
their bank independent setting. Here only move the global control
settings and the independent registers
Il 23/09/21 13:58, Yong Wu ha scritto:
Prepare for adding bankid, also no functional change.
In the previous SoC, each a iova_region is a domain; In the multi-banks
case, each a bank is a domain, then the original function name
"mtk_iommu_get_domain_id" is not proper. Use "iova_region_id"
Il 23/09/21 13:58, Yong Wu ha scritto:
Each bank has some independent registers. thus backup/restore them for
each a bank when suspend and resume.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 39 +++
drivers/iommu/mtk_iommu.h | 14 +++---
Il 23/09/21 13:58, Yong Wu ha scritto:
Prepare for supporting multi banks, Adds two variables in the plat_data:
bank_nr: the bank number that this SoC support;
bank_enable: list if the banks is enabled.
Add them for all the current SoC, bank_nr always is 1 and only
bank_enable[0] is enabled.
Il 23/09/21 13:58, Yong Wu ha scritto:
Prepare for supporting multi-banks for the IOMMU HW, No functional change.
Add a new structure(mtk_iommu_bank_data) for each a bank. Each a bank have
the independent HW base/IRQ/tlb-range ops, and each a bank has its special
iommu-domain(independent
On Tue, Jan 04, 2022 at 02:51:55PM +, Wei Liu wrote:
> > Please stub out all of swiotlb_mem_remap instead of the ifdef inside the
> > function.
>
> Does this look okay to you?
Yes, thanks!
___
iommu mailing list
iommu@lists.linux-foundation.org
On Sun, Jan 02, 2022 at 11:54:46PM -0800, Christoph Hellwig wrote:
> On Fri, Dec 31, 2021 at 11:56:40AM -0500, Tianyu Lan wrote:
> > From: Tianyu Lan
> >
> > HAS_IOMEM option may not be selected on some platforms(e.g, s390) and this
> > will cause compile error due to miss memremap()
On Tue, Jan 04, 2022 at 08:39:11AM -0400, Jason Gunthorpe wrote:
> On Tue, Jan 04, 2022 at 02:08:36AM -0800, Christoph Hellwig wrote:
> > All these bus callouts still looks horrible and just create tons of
> > boilerplate code.
>
> Yes, Lu - Greg asked questions then didn't respond to their
On Tue, Jan 04, 2022 at 09:56:30AM +0800, Lu Baolu wrote:
> v5:
> - Move kernel dma ownership auto-claiming from driver core to bus
> callback. (Greg)
> - Refactor the iommu interfaces to make them more specific.
> (Jason/Robin)
> - Simplify the dma ownership implementation by
On Tue, Jan 04, 2022 at 02:08:36AM -0800, Christoph Hellwig wrote:
> All these bus callouts still looks horrible and just create tons of
> boilerplate code.
Yes, Lu - Greg asked questions then didn't respond to their answers
meaning he accepts them, you should stick with the v4 version.
Jason
All these bus callouts still looks horrible and just create tons of
boilerplate code.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Tue, Jan 04, 2022 at 09:56:31AM +0800, Lu Baolu wrote:
> Multiple devices may be placed in the same IOMMU group because they
> cannot be isolated from each other. These devices must either be
> entirely under kernel control or userspace control, never a mixture.
>
> This adds dma ownership
45 matches
Mail list logo
