include/exec/cpu-defs.h | 2 + include/exec/exec-all.h | 19 ++++++ accel/tcg/cputlb.c | 23 +++++++ target/arm/helper.c | 133 ++++++++++++++++++++++++++-------------- 4 files changed, 131 insertions(+), 46 deletions(-)
In http://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg04181.html (already upstream) I added a check for ASID changes without realizing that TTBCR_EL1 has the A1 bit, controlling which register actually contains the active ASID. In http://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg04182.html I suggested a set of mmu_idx to flush when the ASID does change. In follow-up, Peter suggested more. I now choose secure vs non-secure mmu_idx based on which register is being modified, not the current state of the cpu. Unless I am mistaken, secure state can write to the non-secure registers. Which means that the current state of the cpu is irrelevant and only the register matters. Peter suggested flushing S1E3 when changing ttbr0_s. I can see how this is overlapped onto the EL3 (Secure Monitor) state, but I cannot see how the ASID is used from EL3. The best evidence I can find for this is that there is no TLBIASID* register that is applicable to flushing EL3; that's not conclusive proof though. So while I'm not sure it's necessary, I'm also not sure it isn't necessary, and so I've included S1E3 in the flush. I now also use the VMID to conditionally invalidate the stage 2 translation state. This shows how I anticipaged @depmap to be used in patch 1. r~ Richard Henderson (4): cputlb: Add tlb_set_asid_for_mmuidx target/arm: Install ASIDs for long-form from EL1 target/arm: Install ASIDs for short-form from EL1 target/arm: Install ASIDs for EL2 include/exec/cpu-defs.h | 2 + include/exec/exec-all.h | 19 ++++++ accel/tcg/cputlb.c | 23 +++++++ target/arm/helper.c | 133 ++++++++++++++++++++++++++-------------- 4 files changed, 131 insertions(+), 46 deletions(-) -- 2.17.2
On Mon, Oct 29, 2018 at 15:53:35 +0000, Richard Henderson wrote: > In http://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg04181.html > (already upstream) I added a check for ASID changes without realizing > that TTBCR_EL1 has the A1 bit, controlling which register actually > contains the active ASID. > > In http://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg04182.html > I suggested a set of mmu_idx to flush when the ASID does change. In > follow-up, Peter suggested more. > > I now choose secure vs non-secure mmu_idx based on which register is being > modified, not the current state of the cpu. Unless I am mistaken, secure > state can write to the non-secure registers. Which means that the current > state of the cpu is irrelevant and only the register matters. > > Peter suggested flushing S1E3 when changing ttbr0_s. I can see how this > is overlapped onto the EL3 (Secure Monitor) state, but I cannot see how > the ASID is used from EL3. The best evidence I can find for this is that > there is no TLBIASID* register that is applicable to flushing EL3; that's > not conclusive proof though. So while I'm not sure it's necessary, I'm > also not sure it isn't necessary, and so I've included S1E3 in the flush. > > I now also use the VMID to conditionally invalidate the stage 2 translation > state. This shows how I anticipaged @depmap to be used in patch 1. I've tested this series and the one it depends on (tlb-dirty). I had yesterday a guest running parallel compilation jobs for ~12h with no issues. So Tested-by: Emilio G. Cota <cota@braap.org> for this and the tlb-dirty series. Richard: the crash I reported on IRC must have been due to unrelated changes. I was testing some TLB experiments over the weekend so I must have forgotten to rebuild. Thanks, Emilio
On 29 October 2018 at 15:53, Richard Henderson <richard.henderson@linaro.org> wrote: > In http://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg04181.html > (already upstream) I added a check for ASID changes without realizing > that TTBCR_EL1 has the A1 bit, controlling which register actually > contains the active ASID. > > In http://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg04182.html > I suggested a set of mmu_idx to flush when the ASID does change. In > follow-up, Peter suggested more. > > I now choose secure vs non-secure mmu_idx based on which register is being > modified, not the current state of the cpu. Unless I am mistaken, secure > state can write to the non-secure registers. Which means that the current > state of the cpu is irrelevant and only the register matters. > > Peter suggested flushing S1E3 when changing ttbr0_s. I can see how this > is overlapped onto the EL3 (Secure Monitor) state, but I cannot see how > the ASID is used from EL3. The best evidence I can find for this is that > there is no TLBIASID* register that is applicable to flushing EL3; that's > not conclusive proof though. So while I'm not sure it's necessary, I'm > also not sure it isn't necessary, and so I've included S1E3 in the flush. > > I now also use the VMID to conditionally invalidate the stage 2 translation > state. This shows how I anticipaged @depmap to be used in patch 1. Hi; just a note that I'm deferring this series to 4.0, so may not get to reviewing it for a bit. thanks -- PMM
On 11/5/18 4:30 PM, Peter Maydell wrote: > On 29 October 2018 at 15:53, Richard Henderson > <richard.henderson@linaro.org> wrote: >> In http://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg04181.html >> (already upstream) I added a check for ASID changes without realizing >> that TTBCR_EL1 has the A1 bit, controlling which register actually >> contains the active ASID. >> >> In http://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg04182.html >> I suggested a set of mmu_idx to flush when the ASID does change. In >> follow-up, Peter suggested more. >> >> I now choose secure vs non-secure mmu_idx based on which register is being >> modified, not the current state of the cpu. Unless I am mistaken, secure >> state can write to the non-secure registers. Which means that the current >> state of the cpu is irrelevant and only the register matters. >> >> Peter suggested flushing S1E3 when changing ttbr0_s. I can see how this >> is overlapped onto the EL3 (Secure Monitor) state, but I cannot see how >> the ASID is used from EL3. The best evidence I can find for this is that >> there is no TLBIASID* register that is applicable to flushing EL3; that's >> not conclusive proof though. So while I'm not sure it's necessary, I'm >> also not sure it isn't necessary, and so I've included S1E3 in the flush. >> >> I now also use the VMID to conditionally invalidate the stage 2 translation >> state. This shows how I anticipaged @depmap to be used in patch 1. > > Hi; just a note that I'm deferring this series to 4.0, so may > not get to reviewing it for a bit. That's fine. By that time I will have folded it into my v8.1 series, since I expect to use the asid field as a part of the VHE extension. r~
On 29 October 2018 at 15:53, Richard Henderson <richard.henderson@linaro.org> wrote: > In http://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg04181.html > (already upstream) I added a check for ASID changes without realizing > that TTBCR_EL1 has the A1 bit, controlling which register actually > contains the active ASID. > > In http://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg04182.html > I suggested a set of mmu_idx to flush when the ASID does change. In > follow-up, Peter suggested more. > > I now choose secure vs non-secure mmu_idx based on which register is being > modified, not the current state of the cpu. Unless I am mistaken, secure > state can write to the non-secure registers. Which means that the current > state of the cpu is irrelevant and only the register matters. > > Peter suggested flushing S1E3 when changing ttbr0_s. I can see how this > is overlapped onto the EL3 (Secure Monitor) state, but I cannot see how > the ASID is used from EL3. The best evidence I can find for this is that > there is no TLBIASID* register that is applicable to flushing EL3; that's > not conclusive proof though. So while I'm not sure it's necessary, I'm > also not sure it isn't necessary, and so I've included S1E3 in the flush. "TLBIASID" flushes EL3, when EL3 is AArch32 and you are in Secure PL1 (ie EL3). From the register spec: "If executed in Secure state when EL3 is using AArch32, the Secure PL1&0 translation regime." The spec's "SecurePL1&0 translation regime" is in QEMU ARMMMUIdx_S1E3. TTBR0(S) contains an ASID if TTBCR(S).EAE is 1. (If EL3 is AArch64 then there's no TTBR0(S), only TTBR_EL3, which doesn't have an ASID.) thanks -- PMM
© 2016 - 2025 Red Hat, Inc.