On Thu, Sep 23, 2021 at 10:26:47AM -0700, Ben Widawsky wrote:
> */
> static int siov_find_pci_dvsec(struct pci_dev *pdev)
> {
> + return pci_find_dvsec_capability(pdev, PCI_VENDOR_ID_INTEL, 5);
> }
I hink the siov_find_pci_dvsec helper is pretty pointless now and can be
folded into its on
On Thu, Sep 23, 2021 at 03:54:46PM +0200, Christophe Leroy wrote:
>
> Le 23/09/2021 à 14:01, Mike Rapoport a écrit :
> > On Thu, Sep 23, 2021 at 11:47:48AM +0200, Christophe Leroy wrote:
> > >
> > >
> > > Le 23/09/2021 à 09:43, Mike Rapoport a écrit :
> > > > From: Mike Rapoport
> > > >
> > >
On Thu, Sep 23, 2021, at 4:22 PM, Luck, Tony wrote:
> On Thu, Sep 23, 2021 at 04:09:18PM -0700, Andy Lutomirski wrote:
>> On Mon, Sep 20, 2021, at 12:23 PM, Fenghua Yu wrote:
>
>> I think this is unnecessarily complicated because it's buying in to the
>> existing ISA misconception that PASID has
On Thu, Sep 23, 2021, at 7:56 PM, Fenghua Yu wrote:
> Hi, Andy,
>
> On Thu, Sep 23, 2021 at 04:17:05PM -0700, Andy Lutomirski wrote:
>> On Mon, Sep 20, 2021, at 12:23 PM, Fenghua Yu wrote:
>> > ENQCMD requires the IA32_PASID MSR has a valid PASID value which was
>> > allocated to the process dur
> From: Lu Baolu
> Sent: Friday, September 24, 2021 10:30 AM
>
> The IOMMU VT-d implementation uses the first level for GPA->HPA
> translation
> by default. Although both the first level and the second level could handle
> the DMA translation, they are different in some way. For example, the
> se
Hi, Andy,
On Thu, Sep 23, 2021 at 04:17:05PM -0700, Andy Lutomirski wrote:
> On Mon, Sep 20, 2021, at 12:23 PM, Fenghua Yu wrote:
> > ENQCMD requires the IA32_PASID MSR has a valid PASID value which was
> > allocated to the process during bind. The MSR could be populated eagerly
> > by an IPI afte
The IOMMU VT-d implementation uses the first level for GPA->HPA translation
by default. Although both the first level and the second level could handle
the DMA translation, they are different in some way. For example, the second
level translation has separate controls for the Access/Dirty page trac
Hi, Josh,
On Thu, Sep 23, 2021 at 05:55:40PM -0700, Josh Poimboeuf wrote:
> On Thu, Sep 23, 2021 at 03:26:14PM +, Fenghua Yu wrote:
> > > > + } else if (op2 == 0x38 && op3 == 0xf8) {
> > > > + if (insn.prefixes.nbytes == 1 &&
> > > > +
On Thu, Sep 23, 2021 at 03:26:14PM +, Fenghua Yu wrote:
> > > + } else if (op2 == 0x38 && op3 == 0xf8) {
> > > + if (insn.prefixes.nbytes == 1 &&
> > > + insn.prefixes.bytes[0] == 0xf2) {
> > > + /* ENQCMD cannot be used in the
On Thu, Sep 23, 2021 at 04:09:18PM -0700, Andy Lutomirski wrote:
> On Mon, Sep 20, 2021, at 12:23 PM, Fenghua Yu wrote:
> I think this is unnecessarily complicated because it's buying in to the
> existing ISA misconception that PASID has anything to do with a task.
> A PASID belongs to an mm, full
On Mon, Sep 20, 2021, at 12:23 PM, Fenghua Yu wrote:
> ENQCMD requires the IA32_PASID MSR has a valid PASID value which was
> allocated to the process during bind. The MSR could be populated eagerly
> by an IPI after the PASID is allocated in bind. But the method was
> disabled in commit 9bfecd0
On Mon, Sep 20, 2021, at 12:23 PM, Fenghua Yu wrote:
> PASIDs are fundamentally hardware resources in a shared address space.
> There is a limited number of them to use ENQCMD on shared workqueue.
> They must be shared and managed. They can not, for instance, be
> statically allocated to processes.
On 9/23/2021 1:26 PM, Ben Widawsky wrote:
Add pci_find_dvsec_capability to locate a Designated Vendor-Specific
Extended Capability with the specified DVSEC ID.
The Designated Vendor-Specific Extended Capability (DVSEC) allows one or
more vendor specific capabilities that aren't tied to the ve
Hi Linus,
On Thu, Sep 23, 2021 at 09:01:46AM -0700, Linus Torvalds wrote:
> On Thu, Sep 23, 2021 at 12:43 AM Mike Rapoport wrote:
> >
> You need to be a LOT more careful.
>
> From a trivial check - exactly because I looked at doing it with a
> script, and decided it's not so easy - I found cases
Add r8a77980 (R-Car V3H) to the list of supported devices. The hardware
is the same as on already-supportred V3M and other R-Car Gen3 chips.
Signed-off-by: Nikita Yushchenko
---
drivers/iommu/ipmmu-vmsa.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers
On Thu, Sep 23, 2021 at 12:05:58AM +0300, Kirill A. Shutemov wrote:
> Unless we find other way to guarantee RIP-relative access, we must use
> fixup_pointer() to access any global variables.
Yah, I've asked compiler folks about any guarantees we have wrt
rip-relative addresses but it doesn't look
On Thu, Sep 23 2021 at 09:40, Tony Luck wrote:
> On Thu, Sep 23, 2021 at 04:36:50PM +0200, Thomas Gleixner wrote:
>> This code is again defining that PASID is entirely restricted to
>> INTEL. It's true, that no other vendor supports this, but PASID is
>> a non-vendor specific concept.
>>
>> Sticki
Reduce maintenance burden of DVSEC query implementation by using the
centralized PCI core implementation.
Cc: iommu@lists.linux-foundation.org
Cc: David Woodhouse
Cc: Lu Baolu
Signed-off-by: Ben Widawsky
---
drivers/iommu/intel/iommu.c | 15 +--
1 file changed, 1 insertion(+), 14 d
Add pci_find_dvsec_capability to locate a Designated Vendor-Specific
Extended Capability with the specified DVSEC ID.
The Designated Vendor-Specific Extended Capability (DVSEC) allows one or
more vendor specific capabilities that aren't tied to the vendor ID of
the PCI component.
DVSEC is critica
Reduce maintenance burden of DVSEC query implementation by using the
centralized PCI core implementation.
There are two obvious places to simply drop in the new core
implementation. There remains find_dvsec_from_pos() which would benefit
from using a core implementation. As that change is less tri
Changes since v1 [3]:
- get_max_afu_index() updated to new interface (Dan)
- siov_find_pci_dvsec updated to new interface (Dan)
- remove unnecessary pci request/release regions with refactor (Dan)
- move @base into cxl_register_map (Dan)
- Expanded the Cc list to include other users of PCIe DVSEC.
Reduce maintenance burden of DVSEC query implementation by using the
centralized PCI core implementation.
Signed-off-by: Ben Widawsky
---
drivers/cxl/pci.c | 20 +---
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c
index 5eaf273
The structure exists to pass around information about register mapping.
Using it more extensively cleans up many existing functions.
Signed-off-by: Ben Widawsky
---
drivers/cxl/cxl.h | 1 +
drivers/cxl/pci.c | 36 +---
2 files changed, 18 insertions(+), 19 deleti
Quoting Dan, "... the request + release regions should probably just be
dropped. It's not like any of the register enumeration would collide
with someone else who already has the registers mapped. The collision
only comes when the registers are mapped for their final usage, and that
will have more
In preparation for moving parts of register mapping to cxl_core, the
cxl_pci driver is refactored to utilize a new helper to find register
blocks by type.
cxl_pci scanned through all register blocks and mapping the ones that
the driver will use. This logic is inverted so that the driver
specifical
In preparation for passing around the Register Block Indicator (RBI) as
a parameter, it is desirable to convert the type to an enum so that the
interface can use a well defined type checked parameter.
As a result of this change, should future versions of the spec add
sparsely defined identifiers,
While interesting to driver developers, the dev_dbg message doesn't do
much except clutter up logs. This information should be attainable
through sysfs, and someday lspci like utilities. This change
additionally helps reduce the LOC in a subsequent patch to refactor some
of cxl_pci register mapping
On Wed, Sep 22, 2021 at 11:07:22PM +0200, Peter Zijlstra wrote:
> On Mon, Sep 20, 2021 at 07:23:45PM +, Fenghua Yu wrote:
> > @@ -538,6 +547,9 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection)
> >
> > cond_local_irq_enable(regs);
> >
> > + if (user_mode(regs) && fixup_pasid_excepti
On Thu, Sep 23, 2021 at 04:36:50PM +0200, Thomas Gleixner wrote:
> On Mon, Sep 20 2021 at 19:23, Fenghua Yu wrote:
> >
> > +#ifdef CONFIG_INTEL_IOMMU_SVM
> > +void pasid_put(struct task_struct *tsk, struct mm_struct *mm);
> > +#else
> > +static inline void pasid_put(struct task_struct *tsk, struc
On Thu, Sep 23, 2021 at 12:43 AM Mike Rapoport wrote:
>
> The core change is in the third patch that makes memblock_free() a
> counterpart of memblock_alloc() and adds memblock_phys_alloc() to be a
^^^
> counterpart of memblock_phys_alloc().
That should be 'memblock_phys_free()'
Hi, Peter,
On Thu, Sep 23, 2021 at 09:17:01AM +0200, Peter Zijlstra wrote:
> On Wed, Sep 22, 2021 at 11:44:41PM +, Fenghua Yu wrote:
>
> > > Since you're making it a fatal error, before doing much of anything
> > > else, you might at well fail decode and keep it all in the x86/decode.c
> > >
On Mon, Sep 20 2021 at 19:23, Fenghua Yu wrote:
>
> +#ifdef CONFIG_INTEL_IOMMU_SVM
> +void pasid_put(struct task_struct *tsk, struct mm_struct *mm);
> +#else
> +static inline void pasid_put(struct task_struct *tsk, struct mm_struct *mm)
> { }
> +#endif
This code is again defining that PASID is
Le 23/09/2021 à 14:01, Mike Rapoport a écrit :
On Thu, Sep 23, 2021 at 11:47:48AM +0200, Christophe Leroy wrote:
Le 23/09/2021 à 09:43, Mike Rapoport a écrit :
From: Mike Rapoport
For ages memblock_free() interface dealt with physical addresses even
despite the existence of memblock_alloc
> From: Jason Gunthorpe
> Sent: Thursday, September 23, 2021 9:31 PM
>
> On Thu, Sep 23, 2021 at 01:20:55PM +, Tian, Kevin wrote:
>
> > > > this is not a flow for mdev. It's also required for pdev on Intel
> > > > platform,
> > > > because the pasid table is in HPA space thus must be manage
On Thu, Sep 23, 2021 at 01:20:55PM +, Tian, Kevin wrote:
> > > this is not a flow for mdev. It's also required for pdev on Intel
> > > platform,
> > > because the pasid table is in HPA space thus must be managed by host
> > > kernel. Even no translation we still need the user to provide the p
> From: Jason Gunthorpe
> Sent: Thursday, September 23, 2021 9:02 PM
>
> On Thu, Sep 23, 2021 at 12:45:17PM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, September 23, 2021 8:31 PM
> > >
> > > On Thu, Sep 23, 2021 at 12:22:23PM +, Tian, Kevin wrote:
> > > > > Fr
On 9/23/21 9:43 AM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> For ages memblock_free() interface dealt with physical addresses even
> despite the existence of memblock_alloc_xx() functions that return a
> virtual pointer.
>
> Introduce memblock_phys_free() for freeing physical ranges and re
On Thu, Sep 23, 2021 at 12:45:17PM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, September 23, 2021 8:31 PM
> >
> > On Thu, Sep 23, 2021 at 12:22:23PM +, Tian, Kevin wrote:
> > > > From: Jason Gunthorpe
> > > > Sent: Thursday, September 23, 2021 8:07 PM
> > > >
> >
> From: Jason Gunthorpe
> Sent: Thursday, September 23, 2021 8:31 PM
>
> On Thu, Sep 23, 2021 at 12:22:23PM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, September 23, 2021 8:07 PM
> > >
> > > On Thu, Sep 23, 2021 at 09:14:58AM +, Tian, Kevin wrote:
> > >
> > >
On Thu, Sep 23, 2021 at 12:22:23PM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, September 23, 2021 8:07 PM
> >
> > On Thu, Sep 23, 2021 at 09:14:58AM +, Tian, Kevin wrote:
> >
> > > currently the type is aimed to differentiate three usages:
> > >
> > > - kernel-man
> From: Jason Gunthorpe
> Sent: Thursday, September 23, 2021 8:07 PM
>
> On Thu, Sep 23, 2021 at 09:14:58AM +, Tian, Kevin wrote:
>
> > currently the type is aimed to differentiate three usages:
> >
> > - kernel-managed I/O page table
> > - user-managed I/O page table
> > - shared I/O page t
On Thu, Sep 23, 2021 at 12:05:29PM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, September 23, 2021 7:27 PM
> >
> > On Thu, Sep 23, 2021 at 11:15:24AM +0100, Jean-Philippe Brucker wrote:
> >
> > > So we can only tell userspace "No_snoop is not supported" (provided we
>
On Thu, Sep 23, 2021 at 09:14:58AM +, Tian, Kevin wrote:
> currently the type is aimed to differentiate three usages:
>
> - kernel-managed I/O page table
> - user-managed I/O page table
> - shared I/O page table (e.g. with mm, or ept)
Creating a shared ios is something that should probably b
> From: Jason Gunthorpe
> Sent: Thursday, September 23, 2021 7:27 PM
>
> On Thu, Sep 23, 2021 at 11:15:24AM +0100, Jean-Philippe Brucker wrote:
>
> > So we can only tell userspace "No_snoop is not supported" (provided we
> > even want to allow them to enable No_snoop). Users in control of stage-
Enable the multi-bank functions for infra-iommu. We put PCIE in bank0
and USB in the last bank(bank4). and we don't use the other banks
currently, disable them.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers
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 +++---
2 files changed, 38 insertions(+), 15 dele
The registers for each bank of the IOMMU base are in order, delta is
0x1000. Initialise the base for each bank.
For all the previous SoC, we only have bank0. thus use "do {} while()"
to allow bank0 always go.
When removing the device, Not always all the banks are initialised, it
depend on if ther
We preassign some ports in a special bank via the new defined
bank_portmsk. Put it in the plat_data means it is not expected to be
adjusted dynamically.
If the iommu id in the iommu consumer's dtsi node is inside this
bank_portmsk, then we switch it to this special iommu bank, and initialise
the I
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" instead of
"domain_id".
Signed-off-by: Yong Wu
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.
Signed-off-by: Yong Wu
---
drivers/iommu/
The mt8195 IOMMU HW max support 5 banks, and regarding the banks'
registers, it looks like:
|bank0 | bank1 | bank2 | bank3 | bank4|
|global |
|control| null
|regs |
-
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 pgtable), thus, also move the domain information
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 together.
Signed-off-by: Yong Wu
---
drivers/io
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
---
drivers/iommu/mtk_iommu.c | 51 +--
1 file changed, 27 insertions(+), 24 deletions(-)
diff --git a/drivers/iommu/
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
---
drivers/iommu/mtk_iommu.c | 42 +++
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 43 insertions(+)
diff --git a/drivers/iommu/
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)
{
struct of_phandle_args iommu_spec = { .args_count
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 return value for mtk_iommu_config.
Signed-o
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
---
drivers/iommu/mtk_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/driver
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
---
drivers/iommu/mtk_iommu.c | 3 +--
1 file ch
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
---
drivers/iommu/mtk_iommu.c | 18 ++
1 file change
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, this is
only needed for MM IOMMU. and all
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
---
drivers/iommu/mtk_iommu.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/driv
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.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu
On Thu, Sep 23, 2021 at 11:47:48AM +0200, Christophe Leroy wrote:
>
>
> Le 23/09/2021 à 09:43, Mike Rapoport a écrit :
> > From: Mike Rapoport
> >
> > For ages memblock_free() interface dealt with physical addresses even
> > despite the existence of memblock_alloc_xx() functions that return a
>
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 calulation and it
always has this IOVA_34 fla
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 callback
c) tlb flush range fail case
d) io
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 there may be other HW also use
that power-d
The MediaTek IOMMU don't care about granule when tlb flushing.
Remove this variable.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index ab484d20b441..44cf5547d0
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
---
drivers/iommu/mtk_iommu.c | 25 ++---
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 for_each_m4u in this tlb_sync_all. Remove it.
S
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
---
drivers/iommu/mtk_iommu.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.
In the infra iommu, we should disable DCM. add a new flag for this.
Signed-off-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 00d9ae3dc88a..4e1b01fd58b0 100644
--- a
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 region.
CCU still is 8G-12G. Don't change it he
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 non-sharing pgtable).
Currently we use for_each_m4u
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 > /sys/bus/platform/drivers/mtk-iommu/unbind
[ 51.
In the commit 4f956c97d26b ("iommu/mediatek: Move domain_finalise into
attach_device"), I overlooked the sharing pgtable case.
After that commit, the "data" in the mtk_iommu_domain_finalise always is
the data of the current IOMMU HW. Fix this for the sharing pgtable case.
Only affect mt2712 which
In mt8195, we have a new IOMMU that is for INFRA IOMMU. its masters
mainly are PCIe and USB. Different with MM IOMMU, all these masters
connect with IOMMU directly, there is no mediatek,larbs property for
infra IOMMU.
Another thing is about PCIe ports. currently the function
"of_iommu_configure_de
This patch adds descriptions for mt8195 IOMMU which also use ARM
Short-Descriptor translation table format.
In mt8195, there are two smi-common HW and IOMMU, one is for vdo(video
output), the other is for vpp(video processing pipe). They connects
with different smi-larbs, then some setting(larbid_
This patchset adds MT8195 iommu support.
MT8195 have 3 IOMMU HWs. 2 IOMMU HW is for multimedia, and 1 IOMMU HW is
for infra-master, like PCIe/USB.
About the 2 MM IOMMU HW, something like this:
IOMMU(VDO) IOMMU(VPP)
| |
SMI_COMMON(VDO) SMI_
On Thu, Sep 23, 2021 at 09:25:27AM +0200, Eric Auger wrote:
> Hi,
>
> On 9/22/21 3:00 AM, Jason Gunthorpe wrote:
> > On Wed, Sep 22, 2021 at 12:54:02AM +, Tian, Kevin wrote:
> >>> From: Jason Gunthorpe
> >>> Sent: Wednesday, September 22, 2021 12:01 AM
> >>>
> One open about how to orga
On Thu, Sep 23, 2021 at 03:38:10AM +, Tian, Kevin wrote:
> > From: Tian, Kevin
> > Sent: Thursday, September 23, 2021 11:11 AM
> >
> > >
> > > The required behavior for iommufd is to have the IOMMU ignore the
> > > no-snoop bit so that Intel HW can disable wbinvd. This bit should be
> > > clea
On Thu, Sep 23, 2021 at 03:10:47AM +, Tian, Kevin wrote:
> Disabling wbinvd is one purpose. imo the more important intention
> is that iommu vendor uses different PTE formats between snoop and
> !snoop.
The PTE format for userspace is communicated through the format input,
not through random
On Mon, Sep 20 2021 at 19:23, Fenghua Yu wrote:
> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
> index c8def1b7f8fb..8a89b2cecd77 100644
> --- a/arch/x86/kernel/fpu/xstate.c
> +++ b/arch/x86/kernel/fpu/xstate.c
> @@ -1289,3 +1289,62 @@ int proc_pid_arch_status(struct seq
On Thu, Sep 23, 2021 at 11:15:24AM +0100, Jean-Philippe Brucker wrote:
> So we can only tell userspace "No_snoop is not supported" (provided we
> even want to allow them to enable No_snoop). Users in control of stage-1
> tables can create non-cacheable mappings through MAIR attributes.
My point i
On Thu, Sep 23, 2021 at 03:10:47AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, September 23, 2021 7:50 AM
> >
> > On Wed, Sep 22, 2021 at 03:24:07PM -0600, Alex Williamson wrote:
> > > On Sun, 19 Sep 2021 14:38:38 +0800
> > > Liu Yi L wrote:
> > >
> > > > +struct iomm
Le 23/09/2021 à 09:43, Mike Rapoport a écrit :
From: Mike Rapoport
For ages memblock_free() interface dealt with physical addresses even
despite the existence of memblock_alloc_xx() functions that return a
virtual pointer.
Introduce memblock_phys_free() for freeing physical ranges and repurp
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 10:09 PM
>
> On Wed, Sep 22, 2021 at 03:40:25AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, September 22, 2021 1:45 AM
> > >
> > > On Sun, Sep 19, 2021 at 02:38:39PM +0800, Liu Yi L wrote:
> > > > This
On 23.09.21 09:43, Mike Rapoport wrote:
From: Mike Rapoport
For ages memblock_free() interface dealt with physical addresses even
despite the existence of memblock_alloc_xx() functions that return a
virtual pointer.
Introduce memblock_phys_free() for freeing physical ranges and repurpose
membl
On 23.09.21 09:43, Mike Rapoport wrote:
From: Mike Rapoport
free_p2m_page() wrongly passes a virtual pointer to memblock_free() that
treats it as a physical address.
Call memblock_free_ptr() instead that gets a virtual address to free the
memory.
Signed-off-by: Mike Rapoport
Reviewed-by: J
From: Mike Rapoport
For ages memblock_free() interface dealt with physical addresses even
despite the existence of memblock_alloc_xx() functions that return a
virtual pointer.
Introduce memblock_phys_free() for freeing physical ranges and repurpose
memblock_free() to free virtual pointers to mak
From: Mike Rapoport
free_p2m_page() wrongly passes a virtual pointer to memblock_free() that
treats it as a physical address.
Call memblock_free_ptr() instead that gets a virtual address to free the
memory.
Signed-off-by: Mike Rapoport
---
arch/x86/xen/p2m.c | 2 +-
1 file changed, 1 insertio
From: Mike Rapoport
Memory allocation of numa_distance uses memblock_phys_alloc_range() without
actual range limits, converts the returned physical address to virtual and
then only uses the virtual address for further initialization.
Simplify this by replacing memblock_phys_alloc_range() with
me
From: Mike Rapoport
Hi,
Following the discussion on [1] this is the fix for memblock freeing APIs
mismatch.
The first patch is a cleanup of numa_distance allocation in arch_numa I've
spotted during the conversion.
The second patch is a fix for Xen memory freeing on some of the error
paths.
Th
Hi,
On 9/22/21 3:00 AM, Jason Gunthorpe wrote:
> On Wed, Sep 22, 2021 at 12:54:02AM +, Tian, Kevin wrote:
>>> From: Jason Gunthorpe
>>> Sent: Wednesday, September 22, 2021 12:01 AM
>>>
One open about how to organize the device nodes under
>>> /dev/vfio/devices/.
This RFC adopts a s
On Wed, Sep 22, 2021 at 11:44:41PM +, Fenghua Yu wrote:
> > Since you're making it a fatal error, before doing much of anything
> > else, you might at well fail decode and keep it all in the x86/decode.c
> > file, no need to spread this 'knowledge' any further.
> Is the following updated patc
On Wed, Sep 22, 2021 at 02:33:09PM -0700, Dave Hansen wrote:
> On 9/22/21 2:11 PM, Peter Zijlstra wrote:
> >>> +static bool fixup_pasid_exception(void)
> >>> +{
> >>> + if (!cpu_feature_enabled(X86_FEATURE_ENQCMD))
> >>> + return false;
> >>> +
> >>> + return __fixup_pasid_exception();
> >>
On Wed, Sep 22, 2021 at 09:26:10PM +, Luck, Tony wrote:
> >> > +static bool fixup_pasid_exception(void)
> >> > +{
> >> > +if (!cpu_feature_enabled(X86_FEATURE_ENQCMD))
> >> > +return false;
> >> > +
> >> > +return __fixup_pasid_exception();
> >> > +}
> >
> > That
97 matches
Mail list logo
