• State Accepted Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 19 subscribers
  • Views 7530 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Some questions about the SMMU of JUNO SoC

wangyong

JUNO SoC provides additional support for virtualization except Cortex-A57/A53 as follows:
The CoreLink GIC-400.
Stage 2 page table translation for masters, that the following provide:
A CoreLink MMU-401 System Memory Management Unit (SMMU) for the following:
- The Embedded Trace Router (ETR).
- PCI Express.
- Each HDLCD controller.
- The DMA-330.
- Thin Links, TLX-400.
A CoreLink MMU-400 SMMU for the Mali-T624 GPU.
Note: The MMU-400 does not support the AArch64 page table format.

1. Since MMU-400 is only compatible with ARMv7 LPAE page table formats, why does it connect with Mali-T624 GPU for virtualization in a ARMv8 SoC?
2. MMU-401 is compatible with ARMv7 and ARMv8, but it only supports Stage 2 address translation. I find that Stage 1 address translation is mainly useful for memory fragmentation management and Stage 2 address translation is intended to benefit Virtual Machine Monitors from System-MMU-Whitepaper-v8.0.pdf. The masters that connect with MMU-401 in JUNO SoC don't have their own MMU, so do the outside SMMUs need also support Stage 1 address translation for memory fragmentation management and virtualization?
Does Stage 2 address translation also support memory fragmentation management?

3.Why not directly use MMU-500 for virtualization in JUNO SoC?

Parents
  • 0

    Hello,

    1. A few things to note for this one:


    • The ARMv8 AArch64 long descriptor format is an evolution of the ARMv7 LPAE descriptor format. The only difference between them is that the AArch64 descriptor supports up to 48-bit virtual address spaces, whereas LPAE only supports 40-bit. However, this means that if you limit the size of your virtual address space in AArch64 to 40-bits or less (using TCR_ELx.T0SZ), the two descriptors are identical.
    • A slight disclaimer here as we're not 100% certain, but we're fairly sure that the MMU-400 in front of the Mali-T624 is not actually used by the currently-released software stack deliverables (both the ARM Connected Community and Linaro LSK versions). You should keep in mind that the Juno is a development and prototyping platform, not a commercial system, so it incorporates a number of peripherals that are not strictly necessary but are there to allow for experimentation.

    2. The most common use-case for an SMMU is to allow other masters (DMA, GPU, etc) to see the same view of memory as the operating system, and for this we only need the 2nd stage of translation. This allows for the same driver code to be used in both virtualised and non-virtualised systems without costly trapping in software to the hypervisor. An SMMU supporting 1st stage translations would be useful for implementing userspace drivers, especially for scatter-gather scenarios such as sharing sparse memory buffers, i.e. making non-continguous blocks of physical memory appear as a single contiguous block in the virtual address space.


    3. This is most likely because the MMU-500 wasn't available at the time that the Juno SoC was being designed.


    I hope this helps,

    Ash.

Reply
  • 0

    Hello,

    1. A few things to note for this one:


    • The ARMv8 AArch64 long descriptor format is an evolution of the ARMv7 LPAE descriptor format. The only difference between them is that the AArch64 descriptor supports up to 48-bit virtual address spaces, whereas LPAE only supports 40-bit. However, this means that if you limit the size of your virtual address space in AArch64 to 40-bits or less (using TCR_ELx.T0SZ), the two descriptors are identical.
    • A slight disclaimer here as we're not 100% certain, but we're fairly sure that the MMU-400 in front of the Mali-T624 is not actually used by the currently-released software stack deliverables (both the ARM Connected Community and Linaro LSK versions). You should keep in mind that the Juno is a development and prototyping platform, not a commercial system, so it incorporates a number of peripherals that are not strictly necessary but are there to allow for experimentation.

    2. The most common use-case for an SMMU is to allow other masters (DMA, GPU, etc) to see the same view of memory as the operating system, and for this we only need the 2nd stage of translation. This allows for the same driver code to be used in both virtualised and non-virtualised systems without costly trapping in software to the hypervisor. An SMMU supporting 1st stage translations would be useful for implementing userspace drivers, especially for scatter-gather scenarios such as sharing sparse memory buffers, i.e. making non-continguous blocks of physical memory appear as a single contiguous block in the virtual address space.


    3. This is most likely because the MMU-500 wasn't available at the time that the Juno SoC was being designed.


    I hope this helps,

    Ash.

Children