Re: [question] Assign multiple devices from different SMMUs to a arm_smmu_domain
On 2021/9/7 17:43, Robin Murphy wrote: On 2021-09-07 08:41, Kunkun Jiang wrote: Hi all, I am working on VFIO DMA dirty pages tracking based on ARM SMMU HTTU, and have done a lot of testing.In the test, I found a problem that greatly affects performance of VFIO DMA dirty pages tracking. According to the current arm-smmu-v3 driver, multiple VFIO pass-through device comes from different SMMUs will be assigned to different arm_smmu_domain. It will create page table for each arm_smmu_domain, even though these page tables are exactly the same. Bacause dirty pages tracking needs to traverse the page table, multiple page tables will make performance worse. I learned the ARM SMMUv3 spec and had some exchanges with my colleagues who work on SMMU hardware. I did not find the restriction that multiple SMMUs cannot share the same page table. We migth be able to do this like x86 IOMMU. If I have missed something, please point it out. Sure, it's not impossible, there are just a lot of fiddly considerations, mostly around how to handle SMMU instances with different capabilities. We haven't had a strong need to support this case so far, so we've simply been avoiding all that complexity. Yes, there's a lot to consider here. I'll try to analyze it carefully. We can discuss some of the difficulties in the future. From the perspective of improving the performance of VFIO DMA dirty pages tracking, it is worth supporting this feature. Thanks, Kunkun Jiang Robin. Looking forward to your suggestions.๐ Thanks, Kunkun Jiang . ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/5] dt-bindings: reserved-memory: Document memory region specifier
On Tue, Sep 07, 2021 at 10:33:24AM -0500, Rob Herring wrote: > On Fri, Sep 3, 2021 at 10:36 AM Thierry Reding > wrote: > > > > On Fri, Sep 03, 2021 at 09:36:33AM -0500, Rob Herring wrote: > > > On Fri, Sep 3, 2021 at 8:52 AM Thierry Reding > > > wrote: > > > > > > > > On Fri, Sep 03, 2021 at 08:20:55AM -0500, Rob Herring wrote: > > > > > On Wed, Sep 1, 2021 at 9:13 AM Thierry Reding > > > > > wrote: > > > > > > > > > > > > On Fri, Jul 02, 2021 at 05:16:25PM +0300, Dmitry Osipenko wrote: > > > > > > > 01.07.2021 21:14, Thierry Reding ะฟะธัะตั: > > > > > > > > On Tue, Jun 08, 2021 at 06:51:40PM +0200, Thierry Reding wrote: > > > > > > > >> On Fri, May 28, 2021 at 06:54:55PM +0200, Thierry Reding wrote: > > > > > > > >>> On Thu, May 20, 2021 at 05:03:06PM -0500, Rob Herring wrote: > > > > > > > On Fri, Apr 23, 2021 at 06:32:30PM +0200, Thierry Reding > > > > > > > wrote: > > > > > > > > From: Thierry Reding > > > > > > > > > > > > > > > > Reserved memory region phandle references can be > > > > > > > > accompanied by a > > > > > > > > specifier that provides additional information about how > > > > > > > > that specific > > > > > > > > reference should be treated. > > > > > > > > > > > > > > > > One use-case is to mark a memory region as needing an > > > > > > > > identity mapping > > > > > > > > in the system's IOMMU for the device that references the > > > > > > > > region. This is > > > > > > > > needed for example when the bootloader has set up hardware > > > > > > > > (such as a > > > > > > > > display controller) to actively access a memory region > > > > > > > > (e.g. a boot > > > > > > > > splash screen framebuffer) during boot. The operating > > > > > > > > system can use the > > > > > > > > identity mapping flag from the specifier to make sure an > > > > > > > > IOMMU identity > > > > > > > > mapping is set up for the framebuffer before IOMMU > > > > > > > > translations are > > > > > > > > enabled for the display controller. > > > > > > > > > > > > > > > > Signed-off-by: Thierry Reding > > > > > > > > --- > > > > > > > > .../reserved-memory/reserved-memory.txt | 21 > > > > > > > > +++ > > > > > > > > include/dt-bindings/reserved-memory.h | 8 +++ > > > > > > > > 2 files changed, 29 insertions(+) > > > > > > > > create mode 100644 include/dt-bindings/reserved-memory.h > > > > > > > > > > > > > > Sorry for being slow on this. I have 2 concerns. > > > > > > > > > > > > > > First, this creates an ABI issue. A DT with cells in > > > > > > > 'memory-region' > > > > > > > will not be understood by an existing OS. I'm less concerned > > > > > > > about this > > > > > > > if we address that with a stable fix. (Though I'm pretty > > > > > > > sure we've > > > > > > > naively added #?-cells in the past ignoring this issue.) > > > > > > > >>> > > > > > > > >>> A while ago I had proposed adding memory-region*s* as an > > > > > > > >>> alternative > > > > > > > >>> name for memory-region to make the naming more consistent > > > > > > > >>> with other > > > > > > > >>> types of properties (think clocks, resets, gpios, ...). If we > > > > > > > >>> added > > > > > > > >>> that, we could easily differentiate between the "legacy" > > > > > > > >>> cases where > > > > > > > >>> no #memory-region-cells was allowed and the new cases where > > > > > > > >>> it was. > > > > > > > >>> > > > > > > > Second, it could be the bootloader setting up the reserved > > > > > > > region. If a > > > > > > > node already has 'memory-region', then adding more regions > > > > > > > is more > > > > > > > complicated compared to adding new properties. And defining > > > > > > > what each > > > > > > > memory-region entry is or how many in schemas is impossible. > > > > > > > >>> > > > > > > > >>> It's true that updating the property gets a bit complicated, > > > > > > > >>> but it's > > > > > > > >>> not exactly rocket science. We really just need to splice the > > > > > > > >>> array. I > > > > > > > >>> have a working implemention for this in U-Boot. > > > > > > > >>> > > > > > > > >>> For what it's worth, we could run into the same issue with > > > > > > > >>> any new > > > > > > > >>> property that we add. Even if we renamed this to > > > > > > > >>> iommu-memory-region, > > > > > > > >>> it's still possible that a bootloader may have to update this > > > > > > > >>> property > > > > > > > >>> if it already exists (it could be hard-coded in DT, or it > > > > > > > >>> could have > > > > > > > >>> been added by some earlier bootloader or firmware). > > > > > > > >>> > > > > > > > Both could be addressed with a new property. Perhaps > > > > > > > something like > > > > > > > 'iommu-memory-region = <&phandle>;'. I think the 'iommu' > >
Re: [PATCH v2 1/5] dt-bindings: reserved-memory: Document memory region specifier
On Fri, Sep 3, 2021 at 10:36 AM Thierry Reding wrote: > > On Fri, Sep 03, 2021 at 09:36:33AM -0500, Rob Herring wrote: > > On Fri, Sep 3, 2021 at 8:52 AM Thierry Reding > > wrote: > > > > > > On Fri, Sep 03, 2021 at 08:20:55AM -0500, Rob Herring wrote: > > > > On Wed, Sep 1, 2021 at 9:13 AM Thierry Reding > > > > wrote: > > > > > > > > > > On Fri, Jul 02, 2021 at 05:16:25PM +0300, Dmitry Osipenko wrote: > > > > > > 01.07.2021 21:14, Thierry Reding ะฟะธัะตั: > > > > > > > On Tue, Jun 08, 2021 at 06:51:40PM +0200, Thierry Reding wrote: > > > > > > >> On Fri, May 28, 2021 at 06:54:55PM +0200, Thierry Reding wrote: > > > > > > >>> On Thu, May 20, 2021 at 05:03:06PM -0500, Rob Herring wrote: > > > > > > On Fri, Apr 23, 2021 at 06:32:30PM +0200, Thierry Reding wrote: > > > > > > > From: Thierry Reding > > > > > > > > > > > > > > Reserved memory region phandle references can be accompanied > > > > > > > by a > > > > > > > specifier that provides additional information about how that > > > > > > > specific > > > > > > > reference should be treated. > > > > > > > > > > > > > > One use-case is to mark a memory region as needing an > > > > > > > identity mapping > > > > > > > in the system's IOMMU for the device that references the > > > > > > > region. This is > > > > > > > needed for example when the bootloader has set up hardware > > > > > > > (such as a > > > > > > > display controller) to actively access a memory region (e.g. > > > > > > > a boot > > > > > > > splash screen framebuffer) during boot. The operating system > > > > > > > can use the > > > > > > > identity mapping flag from the specifier to make sure an > > > > > > > IOMMU identity > > > > > > > mapping is set up for the framebuffer before IOMMU > > > > > > > translations are > > > > > > > enabled for the display controller. > > > > > > > > > > > > > > Signed-off-by: Thierry Reding > > > > > > > --- > > > > > > > .../reserved-memory/reserved-memory.txt | 21 > > > > > > > +++ > > > > > > > include/dt-bindings/reserved-memory.h | 8 +++ > > > > > > > 2 files changed, 29 insertions(+) > > > > > > > create mode 100644 include/dt-bindings/reserved-memory.h > > > > > > > > > > > > Sorry for being slow on this. I have 2 concerns. > > > > > > > > > > > > First, this creates an ABI issue. A DT with cells in > > > > > > 'memory-region' > > > > > > will not be understood by an existing OS. I'm less concerned > > > > > > about this > > > > > > if we address that with a stable fix. (Though I'm pretty sure > > > > > > we've > > > > > > naively added #?-cells in the past ignoring this issue.) > > > > > > >>> > > > > > > >>> A while ago I had proposed adding memory-region*s* as an > > > > > > >>> alternative > > > > > > >>> name for memory-region to make the naming more consistent with > > > > > > >>> other > > > > > > >>> types of properties (think clocks, resets, gpios, ...). If we > > > > > > >>> added > > > > > > >>> that, we could easily differentiate between the "legacy" cases > > > > > > >>> where > > > > > > >>> no #memory-region-cells was allowed and the new cases where it > > > > > > >>> was. > > > > > > >>> > > > > > > Second, it could be the bootloader setting up the reserved > > > > > > region. If a > > > > > > node already has 'memory-region', then adding more regions is > > > > > > more > > > > > > complicated compared to adding new properties. And defining > > > > > > what each > > > > > > memory-region entry is or how many in schemas is impossible. > > > > > > >>> > > > > > > >>> It's true that updating the property gets a bit complicated, > > > > > > >>> but it's > > > > > > >>> not exactly rocket science. We really just need to splice the > > > > > > >>> array. I > > > > > > >>> have a working implemention for this in U-Boot. > > > > > > >>> > > > > > > >>> For what it's worth, we could run into the same issue with any > > > > > > >>> new > > > > > > >>> property that we add. Even if we renamed this to > > > > > > >>> iommu-memory-region, > > > > > > >>> it's still possible that a bootloader may have to update this > > > > > > >>> property > > > > > > >>> if it already exists (it could be hard-coded in DT, or it could > > > > > > >>> have > > > > > > >>> been added by some earlier bootloader or firmware). > > > > > > >>> > > > > > > Both could be addressed with a new property. Perhaps something > > > > > > like > > > > > > 'iommu-memory-region = <&phandle>;'. I think the 'iommu' > > > > > > prefix is > > > > > > appropriate given this is entirely because of the IOMMU being > > > > > > in the > > > > > > mix. I might feel differently if we had other uses for cells, > > > > > > but I > > > > > > don't really see it in this
Re: [question] Assign multiple devices from different SMMUs to a arm_smmu_domain
On 2021-09-07 08:41, Kunkun Jiang wrote: Hi all, I am working on VFIO DMA dirty pages tracking based on ARM SMMU HTTU, and have done a lot of testing.In the test, I found a problem that greatly affects performance of VFIO DMA dirty pages tracking. According to the current arm-smmu-v3 driver, multiple VFIO pass-through device comes from different SMMUs will be assigned to different arm_smmu_domain. It will create page table for each arm_smmu_domain, even though these page tables are exactly the same. Bacause dirty pages tracking needs to traverse the page table, multiple page tables will make performance worse. I learned the ARM SMMUv3 spec and had some exchanges with my colleagues who work on SMMU hardware. I did not find the restriction that multiple SMMUs cannot share the same page table. We migth be able to do this like x86 IOMMU. If I have missed something, please point it out. Sure, it's not impossible, there are just a lot of fiddly considerations, mostly around how to handle SMMU instances with different capabilities. We haven't had a strong need to support this case so far, so we've simply been avoiding all that complexity. Robin. Looking forward to your suggestions.๐ Thanks, Kunkun Jiang ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 2/2] iommu/ipmmu-vmsa: Add support for r8a779a0
Add support for r8a779a0 (R-Car V3U). The IPMMU hardware design
of this SoC differs than others. So, add a new ipmmu_features for it.
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Geert Uytterhoeven
---
drivers/iommu/ipmmu-vmsa.c | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index d38ff29a76e8..d8fe5ba0cb23 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -33,10 +33,10 @@
#define arm_iommu_detach_device(...) do {} while (0)
#endif
-#define IPMMU_CTX_MAX 8U
+#define IPMMU_CTX_MAX 16U
#define IPMMU_CTX_INVALID -1
-#define IPMMU_UTLB_MAX 48U
+#define IPMMU_UTLB_MAX 64U
struct ipmmu_features {
bool use_ns_alias_offset;
@@ -189,8 +189,12 @@ static void ipmmu_write(struct ipmmu_vmsa_device *mmu,
unsigned int offset,
static unsigned int ipmmu_ctx_reg(struct ipmmu_vmsa_device *mmu,
unsigned int context_id, unsigned int reg)
{
- return mmu->features->ctx_offset_base +
- context_id * mmu->features->ctx_offset_stride + reg;
+ unsigned int base = mmu->features->ctx_offset_base;
+
+ if (context_id > 7)
+ base += 0x800 - 8 * 0x40;
+
+ return base + context_id * mmu->features->ctx_offset_stride + reg;
}
static u32 ipmmu_ctx_read(struct ipmmu_vmsa_device *mmu,
@@ -922,6 +926,20 @@ static const struct ipmmu_features
ipmmu_features_rcar_gen3 = {
.utlb_offset_base = 0,
};
+static const struct ipmmu_features ipmmu_features_r8a779a0 = {
+ .use_ns_alias_offset = false,
+ .has_cache_leaf_nodes = true,
+ .number_of_contexts = 16,
+ .num_utlbs = 64,
+ .setup_imbuscr = false,
+ .twobit_imttbcr_sl0 = true,
+ .reserved_context = true,
+ .cache_snoop = false,
+ .ctx_offset_base = 0x1,
+ .ctx_offset_stride = 0x1040,
+ .utlb_offset_base = 0x3000,
+};
+
static const struct of_device_id ipmmu_of_ids[] = {
{
.compatible = "renesas,ipmmu-vmsa",
@@ -959,6 +977,9 @@ static const struct of_device_id ipmmu_of_ids[] = {
}, {
.compatible = "renesas,ipmmu-r8a77995",
.data = &ipmmu_features_rcar_gen3,
+ }, {
+ .compatible = "renesas,ipmmu-r8a779a0",
+ .data = &ipmmu_features_r8a779a0,
}, {
/* Terminator */
},
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 0/2] iommu/ipmmu-vmsa: Add support for r8a779a0
This patch series adds support for r8a779a0 (R-Car V3U).
Changes from v1:
- Add {Ack,Review}ed-by in the patch 1.
- Add support 16 contexts in the patch 2.
- Add Reviewed-by in the patch 2.
https://lore.kernel.org/all/20210901102705.556093-1-yoshihiro.shimoda...@renesas.com/
Yoshihiro Shimoda (2):
dt-bindings: iommu: renesas,ipmmu-vmsa: add r8a779a0 support
iommu/ipmmu-vmsa: Add support for r8a779a0
.../bindings/iommu/renesas,ipmmu-vmsa.yaml| 1 +
drivers/iommu/ipmmu-vmsa.c| 29 ---
2 files changed, 26 insertions(+), 4 deletions(-)
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 1/2] dt-bindings: iommu: renesas, ipmmu-vmsa: add r8a779a0 support
Add support for r8a779a0 (R-Car V3U). Signed-off-by: Yoshihiro Shimoda Acked-by: Rob Herring Reviewed-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml index 02c69a95c332..ce0c715205c6 100644 --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml @@ -43,6 +43,7 @@ properties: - renesas,ipmmu-r8a77980 # R-Car V3H - renesas,ipmmu-r8a77990 # R-Car E3 - renesas,ipmmu-r8a77995 # R-Car D3 + - renesas,ipmmu-r8a779a0 # R-Car V3U reg: maxItems: 1 -- 2.25.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[question] Assign multiple devices from different SMMUs to a arm_smmu_domain
Hi all, I am working on VFIO DMA dirty pages tracking based on ARM SMMU HTTU, and have done a lot of testing.In the test, I found a problem that greatly affects performance of VFIO DMA dirty pages tracking. According to the current arm-smmu-v3 driver, multiple VFIO pass-through device comes from different SMMUs will be assigned to different arm_smmu_domain. It will create page table for each arm_smmu_domain, even though these page tables are exactly the same. Bacause dirty pages tracking needs to traverse the page table, multiple page tables will make performance worse. I learned the ARM SMMUv3 spec and had some exchanges with my colleagues who work on SMMU hardware. I did not find the restriction that multiple SMMUs cannot share the same page table. We migth be able to do this like x86 IOMMU. If I have missed something, please point it out. Looking forward to your suggestions.๐ Thanks, Kunkun Jiang ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/2] iommu/ipmmu-vmsa: Add support for r8a779a0
Hi Shimoda-san,
On Tue, Sep 7, 2021 at 9:29 AM Yoshihiro Shimoda
wrote:
> > From: Geert Uytterhoeven, Sent: Tuesday, September 7, 2021 3:34 PM
> > On Tue, Sep 7, 2021 at 2:02 AM Yoshihiro Shimoda
> > wrote:
> > > > From: Geert Uytterhoeven, Sent: Tuesday, September 7, 2021 12:34 AM
> > > > On Wed, Sep 1, 2021 at 12:27 PM Yoshihiro Shimoda
> > > > wrote:
> > > > > Add support for r8a779a0 (R-Car V3U). The IPMMU hardware design
> > > > > of this SoC differs than others. So, add a new ipmmu_features for it.
> > > > >
> > > > > Signed-off-by: Yoshihiro Shimoda
> > > >
> > > > > --- a/drivers/iommu/ipmmu-vmsa.c
> > > > > +++ b/drivers/iommu/ipmmu-vmsa.c
> > > >
> > > > > @@ -922,6 +922,20 @@ static const struct ipmmu_features
> > > > > ipmmu_features_rcar_gen3 = {
> > > > > .utlb_offset_base = 0,
> > > > > };
> > > > >
> > > > > +static const struct ipmmu_features ipmmu_features_r8a779a0 = {
> > > > > + .use_ns_alias_offset = false,
> > > > > + .has_cache_leaf_nodes = true,
> > > > > + .number_of_contexts = 8,
> > > >
> > > > Shouldn't this be 16?
> > > > Or do you plan to add support for more than 8 contexts later, as that
> > > > would require increasing IPMMU_CTX_MAX, and updating ipmmu_ctx_reg()
> > > > to handle the second bank of 8 contexts?
> > >
> > > I would like to add support for more than 8 contexts later because
> > > I realized that ctx_offset_{base,stride} are not suitable for the second
> > > bank
> > > of 8 contexts...
> >
> > Wouldn't something like below be sufficient?
>
> Thank you for your suggestion!
>
> > static unsigned int ipmmu_ctx_reg(struct ipmmu_vmsa_device *mmu,
> > unsigned int context_id, unsigned int reg)
> > {
> > - return mmu->features->ctx_offset_base +
> > - context_id * mmu->features->ctx_offset_stride + reg;
> > + unsigned int base = mmu->features->ctx_offset_base;
> > +
> > + if (context_id > 7)
> > + base += 0x800 - 8 * 0x1040;
>
> This should be "base += 0x800 - 8 * 0x40;" because the 8th context address is
> 0x18800, not 0x10800.
Doh, I should have written my first thought ("base += FIXME" ;-)
> I'll send v2 patch to support 16 contexts.
> (I'll change IPMMU_CTX_MAX to 16 too.)
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 2/2] iommu/ipmmu-vmsa: Add support for r8a779a0
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Tuesday, September 7, 2021 3:34 PM
>
> Hi Shimoda-san,
>
> On Tue, Sep 7, 2021 at 2:02 AM Yoshihiro Shimoda
> wrote:
> > > From: Geert Uytterhoeven, Sent: Tuesday, September 7, 2021 12:34 AM
> > > On Wed, Sep 1, 2021 at 12:27 PM Yoshihiro Shimoda
> > > wrote:
> > > > Add support for r8a779a0 (R-Car V3U). The IPMMU hardware design
> > > > of this SoC differs than others. So, add a new ipmmu_features for it.
> > > >
> > > > Signed-off-by: Yoshihiro Shimoda
> > >
> > > > --- a/drivers/iommu/ipmmu-vmsa.c
> > > > +++ b/drivers/iommu/ipmmu-vmsa.c
> > >
> > > > @@ -922,6 +922,20 @@ static const struct ipmmu_features
> > > > ipmmu_features_rcar_gen3 = {
> > > > .utlb_offset_base = 0,
> > > > };
> > > >
> > > > +static const struct ipmmu_features ipmmu_features_r8a779a0 = {
> > > > + .use_ns_alias_offset = false,
> > > > + .has_cache_leaf_nodes = true,
> > > > + .number_of_contexts = 8,
> > >
> > > Shouldn't this be 16?
> > > Or do you plan to add support for more than 8 contexts later, as that
> > > would require increasing IPMMU_CTX_MAX, and updating ipmmu_ctx_reg()
> > > to handle the second bank of 8 contexts?
> >
> > I would like to add support for more than 8 contexts later because
> > I realized that ctx_offset_{base,stride} are not suitable for the second
> > bank
> > of 8 contexts...
>
> Wouldn't something like below be sufficient?
Thank you for your suggestion!
> static unsigned int ipmmu_ctx_reg(struct ipmmu_vmsa_device *mmu,
> unsigned int context_id, unsigned int reg)
> {
> - return mmu->features->ctx_offset_base +
> - context_id * mmu->features->ctx_offset_stride + reg;
> + unsigned int base = mmu->features->ctx_offset_base;
> +
> + if (context_id > 7)
> + base += 0x800 - 8 * 0x1040;
This should be "base += 0x800 - 8 * 0x40;" because the 8th context address is
0x18800, not 0x10800.
I'll send v2 patch to support 16 contexts.
(I'll change IPMMU_CTX_MAX to 16 too.)
Best regards,
Yoshihiro Shimoda
> +
> + return base + context_id * mmu->features->ctx_offset_stride + reg;
> }
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
