Message ID | 20220703082419.770989-1-richard.henderson@linaro.org |
---|---|
Headers | show |
Series | target/arm: Implement FEAT_HAFDBS | expand |
On Sun, 3 Jul 2022 at 09:25, Richard Henderson <richard.henderson@linaro.org> wrote: > > This is a major reorg to arm page table walking. While the result > here is "merely" Hardware-assited Access Flag and Dirty Bit Setting > (HAFDBS), the ultimate goal is the Realm Management Extension (RME). > RME "recommends" that HAFDBS be implemented (I_CSLWZ). > > For HAFDBS, being able to find a host pointer for the ram that > backs a given page table entry is required in order to perform the > atomic update to that PTE. The easiest way to find a host pointer > is to use the existing softtlb mechanism. Thus all of the page > table walkers have been adjusted to take an mmu_idx that corresponds > to the regime in which the page table is stored. In some cases, > this is a new "physical" mmu_idx that has a permanent 1-1 mapping. > > For RME, "physical" addresses also have page permissions, coming > from the Root realm Granule Protection Table, which can be thought > of as a third stage page table lookup. So eventually the new > Secure and Nonsecure physical mmu indexes will joined by > Realm and Root physical mmu indexes, and all of them will take > the new Granule Page Table into account. > > Previously, we had A-profile allocate separate mmu_idx for secure > vs non-secure. I've done away with that. Now, I flush all mmu_idx > when SCR_EL3.NS is changed. I did not see how we could reasonably > add 8 more mmu_idx for Realm. Moreover, I had a look through ARM > Trusted Firmware, at the code paths used to change between Secure > and Nonsecure. We wind up flushing all of these mmu_idx anyway while > swapping the EL1+EL2 cpregs, so there is no gain at all in attempting > to keep them live at the same time within qemu. Is there no SMC/interrupt/etc at all which is handled as a "just do the thing at EL3" without dropping down to secure EL2/EL1 ? thanks -- PMM
On 7/4/22 20:24, Peter Maydell wrote: >> Previously, we had A-profile allocate separate mmu_idx for secure >> vs non-secure. I've done away with that. Now, I flush all mmu_idx >> when SCR_EL3.NS is changed. I did not see how we could reasonably >> add 8 more mmu_idx for Realm. Moreover, I had a look through ARM >> Trusted Firmware, at the code paths used to change between Secure >> and Nonsecure. We wind up flushing all of these mmu_idx anyway while >> swapping the EL1+EL2 cpregs, so there is no gain at all in attempting >> to keep them live at the same time within qemu. > > Is there no SMC/interrupt/etc at all which is handled as a "just do the > thing at EL3" without dropping down to secure EL2/EL1 ? I'm sure there is, but it's only swapping between S EL[012] and NS EL[012] that concerned me. Is there something that I'm missing? r~
On Mon, 4 Jul 2022 at 15:58, Richard Henderson <richard.henderson@linaro.org> wrote: > > On 7/4/22 20:24, Peter Maydell wrote: > >> Previously, we had A-profile allocate separate mmu_idx for secure > >> vs non-secure. I've done away with that. Now, I flush all mmu_idx > >> when SCR_EL3.NS is changed. I did not see how we could reasonably > >> add 8 more mmu_idx for Realm. Moreover, I had a look through ARM > >> Trusted Firmware, at the code paths used to change between Secure > >> and Nonsecure. We wind up flushing all of these mmu_idx anyway while > >> swapping the EL1+EL2 cpregs, so there is no gain at all in attempting > >> to keep them live at the same time within qemu. > > > > Is there no SMC/interrupt/etc at all which is handled as a "just do the > > thing at EL3" without dropping down to secure EL2/EL1 ? > > I'm sure there is, but it's only swapping between S EL[012] and NS EL[012] that concerned > me. Is there something that I'm missing? Oh, right, EL3 remains its own mmu_idx, of course. (And I guess also Monitor mode for AArch32 EL3, though the degree to which we care about performance of emulation there is decreasing I suspect.) thanks -- PMM
On Sun, 3 Jul 2022 at 09:25, Richard Henderson <richard.henderson@linaro.org> wrote: > > This is a major reorg to arm page table walking. While the result > here is "merely" Hardware-assited Access Flag and Dirty Bit Setting > (HAFDBS), the ultimate goal is the Realm Management Extension (RME). > RME "recommends" that HAFDBS be implemented (I_CSLWZ). > Richard Henderson (62): > accel/tcg: Introduce PageEntryExtra > target/arm: Enable PageEntryExtra > target/arm: Fix MTE check in sve_ldnfff1_r > target/arm: Record tagged bit for user-only in sve_probe_page > target/arm: Use PageEntryExtra for MTE > target/arm: Use PageEntryExtra for BTI > include/exec: Remove target_tlb_bitN from MemTxAttrs > target/arm: Create GetPhysAddrResult > target/arm: Fix ipa_secure in get_phys_addr > target/arm: Use GetPhysAddrResult in get_phys_addr_lpae > target/arm: Use GetPhysAddrResult in get_phys_addr_v6 > target/arm: Use GetPhysAddrResult in get_phys_addr_v5 > target/arm: Use GetPhysAddrResult in get_phys_addr_pmsav5 > target/arm: Use GetPhysAddrResult in get_phys_addr_pmsav7 > target/arm: Use GetPhysAddrResult in get_phys_addr_pmsav8 > target/arm: Use GetPhysAddrResult in pmsav8_mpu_lookup > target/arm: Remove is_subpage argument to pmsav8_mpu_lookup > target/arm: Add is_secure parameter to v8m_security_lookup > target/arm: Add is_secure parameter to pmsav8_mpu_lookup > target/arm: Add is_secure parameter to get_phys_addr_v5 > target/arm: Add is_secure parameter to get_phys_addr_v6 > target/arm: Add secure parameter to get_phys_addr_pmsav8 > target/arm: Add is_secure parameter to pmsav7_use_background_region > target/arm: Add is_secure parameter to get_phys_addr_lpae > target/arm: Add is_secure parameter to get_phys_addr_pmsav7 > target/arm: Add is_secure parameter to regime_translation_disabled > target/arm: Add is_secure parameter to get_phys_addr_pmsav5 Is it possible to rearrange this patchset so the easy refactoring patches that do "use a struct to return values from get_phys_addr and friends" are at the front (ie before the stuff that touches core code) ? That way they're easy to take into the tree early while the rest of the series is still under review... thanks -- PMM
On 8/12/22 09:31, Peter Maydell wrote: > Is it possible to rearrange this patchset so the easy > refactoring patches that do "use a struct to return > values from get_phys_addr and friends" are at the front > (ie before the stuff that touches core code) ? > That way they're easy to take into the tree early while > the rest of the series is still under review... Yes, I think so. r~