Question1
I was reading this document and found that figure A.11 describes that platform can have on-chip devices connected to the SMMU and peripherals connected through a non-coherent interconnect.
I thought that PE can access all peripherals on the platform through the SMMU, but what is the difference between those two different device types?
If anyone can provide examples of the peripheral and on-chip devices, it would be really helpful to understand those two different types of devices.
Question2
How the memory-mapped devices/registers can be accessible by the PE on ARM architecture?
When It comes to the SMMU, the physical registers of the SMMU for example page 0 registers (e.g., SMMU_IDR0) can be read/written just as exactly same as accessing any other memories with ldr/str instruction.
Or another example would be frame buffer. It seems that PE can access frame buffer addresses which is pre-configured on the board as exactly same as accessing SMMU registers with generic ldr/str instructions.
In the above figure what would be the path from PE to the memories or registers of the memory transactions? Does it go through the SMMU? or directly goes to the peripherals without going through the SMMU??
Question3
Also, it seems that pre-configured physical addresses are used for accessing the peripheral's registers and memories. Does it also mean that the memory transactions of the PE for accessing peripherals registers and memories will be governed by the GPT?
Q1: It's using Device to mean something that can access memory, so an accelerator such as a GPU (B2.3.2). Peripheral is something you access via the bus (B.2.3), so the MMIO registers of something like a timer. A given "thing" might (to system architecture) look both like a peripheral and a device.
For example, the GIC (generic interrupt controller). It is a "device" in that it has a requester port that it uses to read interrupt mapping tables which are held in memory. It is a peripheral, in that it has MMIO registers that the software accesses to configure the interrupt controller.
Q2: As you described, a peripheral would typically have MMIO registers for control and configuration. Those registers would appear somewhere in the physical address space, software would map in location to its VA space and then access the registers with loads and stores.
The diagram you quoted from the spec is simplified. For something like an accelerator, the device would be both a requester (generator of bus traffic) and completer (responding to bus traffic). The MMIO accesses from the PE would target the address(es) associated with the completer port. It's the devices's requester that passes through the SMMU.
Q3: All accesses by the PE will be subject to Granule Protection checks, similar to how accesses are checked by the MMU (when it's enabled). But...
The GPT entry for a given location might assign it to a specific PAS or allow as PASes. For example, the region covering the GIC's MMIO registers would be expected to be configured as permitting all PASes. That's because the GIC internally uses the accessed PAS to determine what conf/state should be accessible. Also, the GPTs can be set to only cover a portion of the address space, with default attributes used for addresses beyond it.
Appreciate all answers! Really helpful. I have one follow-up question about is the accessed PAS? Does it mean that the PAS of the requester?
So what I understand based on your answer is GIC have multiple registers exposed to the PE, but they should not be accessible regardless of the world that PE runs on. For example, there are GIC registers designed to be used by only the TZ for providing secure interrupt, and it should not be configurable by the REALM. To enforce it the GIC has internally checks the accessed PAS (PAS specified on the transaction) and deny the accesses if the pre-set PAS of the destination registers does not match with the PAS of the transaction?
Jaehyuk said:I have one follow-up question about is the accessed PAS? Does it mean that the PAS of the requester?
Yes, although strictly it's the PAS of the transaction that the requester issued.
Jaehyuk said:So what I understand based on your answer is GIC have multiple registers exposed to the PE, but they should not be accessible regardless of the world that PE runs on. For example, there are GIC registers designed to be used by only the TZ for providing secure interrupt, and it should not be configurable by the REALM. To enforce it the GIC has internally checks the accessed PAS (PAS specified on the transaction) and deny the accesses if the pre-set PAS of the destination registers does not match with the PAS of the transaction?
Let's take a concrete example - GICD_ISPENDR<n>. On reads this register returns the pending state of SPIs (Shared Peripheral Interrupts). Writes to this register sets the pending state of SPIs.
The GIC allows interrupts to be assigned to different Security states, this is done via what the GIC calls "Groups". On a read of GICD_ISPENDRn the PAS of the transactions is used by the GIC to control what information it exposes. A Non-secure read will only return information on Non-secure (NS.G1) interrupts. While the same read using the Secure PAS would return information on Non-secure (NS.G1) and Secure (S.G1 & G0) interrupts.
We'd call this completer-side filtering. The GPC check on the Requester allows through accesses with any PAS, and we put the burden on the target completer to use the PAS information appropriately. In the GIC case, to control which interrupts you can/can't see. Other peripherals/devices might use information in slightly different ways.