Re: [PATCH] target/arm: Implement ARMv8.1-VMID16 extension

[Peter Maydell]

On Mon, 10 Feb 2020 at 12:23, Alex Bennée <address@hidden> wrote:
>
>
> Peter Maydell <address@hidden> 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).
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,
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.

thanks
-- PMM