On 2/10/20 1:19 PM, Peter Maydell wrote: > On Mon, 10 Feb 2020 at 12:23, Alex Bennée <alex.ben...@linaro.org> wrote: >> >> >> Peter Maydell <peter.mayd...@linaro.org> writes: >> >>> The ARMv8.1-VMID16 extension extends the VMID from 8 bits to 16 bits: >>> >>> * the ID_AA64MMFR1_EL1.VMIDBits field specifies whether the VMID is >>> 8 or 16 bits >>> * the VMID field in VTTBR_EL2 is extended to 16 bits >>> * VTCR_EL2.VS lets the guest specify whether to use the full 16 bits, >>> or use the backwards-compatible 8 bits >>> >>> For QEMU implementing this is trivial: >>> * we do not track VMIDs in TLB entries, so we never use the VMID >>> field >> >> Not currently but does the VMID allow you to have per-guest page table >> caching? Last time I chatted to rth about potential performance wins we >> discussed how easy it would be to support this in the softmmu now we >> have indirect TLB lookups anyway. Given how much time is currently spent >> expensively re-populating tables we could keep the last couple of id >> tagged tables around for faster switching between sets of tables. > > Yeah, in hardware the whole point of the VMID is to have per-guest > caching of VA-to-PA mappings in the TLB so you don't have to blow > them all away when you switch VM (just as ASID does for processes).
Yep. > The difficulty with QEMU has always been that adding the "and is this > the right VMID/ASID" to the softmmu fastpath code would be expensive, Yep. My current half-baked idea for this does not involve changing the fastpath, but swapping out softmmu tlbs in bulk. Which is possible now that there's a pointer involved, and not 8k of data in an array. > AIUI. If we ever come up with a clever plan for this it should be > no different if the VMID field is 16 vs 8 bits, though. Yep. Reviewed-by: Richard Henderson <richard.hender...@linaro.org> r~
