qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/4] target/arm: Minimize TLB flushing for ASID


From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH 0/4] target/arm: Minimize TLB flushing for ASID changes
Date: Mon, 5 Nov 2018 17:38:32 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

On 11/5/18 4:30 PM, Peter Maydell wrote:
> On 29 October 2018 at 15:53, Richard Henderson
> <address@hidden> 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~




reply via email to

[Prev in Thread] Current Thread [Next in Thread]