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

[Richard Henderson]

On 2/10/20 1:19 PM, Peter Maydell wrote:
> 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).

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 <address@hidden>


r~