[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 00/66] target/arm: Implement FEAT_HAFDBS
From: |
Peter Maydell |
Subject: |
Re: [PATCH v2 00/66] target/arm: Implement FEAT_HAFDBS |
Date: |
Thu, 22 Sep 2022 11:56:18 +0100 |
On Mon, 22 Aug 2022 at 16:28, 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.
Hi; I'm going to take patches 1, 3-16, 18 and 20 into
target-arm.next:
> target/arm: Create GetPhysAddrResult
> 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 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 secure parameter to get_phys_addr_pmsav7
> target/arm: Add is_secure parameter to get_phys_addr_pmsav5
I haven't looked at the second half of the patchset yet -- I'll
come back to this after having worked through the rest of my
to-review queue.
thanks
-- PMM
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [PATCH v2 00/66] target/arm: Implement FEAT_HAFDBS,
Peter Maydell <=