[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DSB does not seem to wait for TLBI completion
From: |
Alex Bennée |
Subject: |
Re: DSB does not seem to wait for TLBI completion |
Date: |
Thu, 18 Nov 2021 18:50:32 +0000 |
User-agent: |
mu4e 1.7.5; emacs 28.0.60 |
Peter Maydell <peter.maydell@linaro.org> writes:
> On Thu, 18 Nov 2021 at 15:46, Idan Horowitz <idan.horowitz@gmail.com> wrote:
>>
>> Hey, I'm running a bare-metal image on QEMU 6.1 and I've encountered the
>> following scenario:
>> After receiving a data abort and mapping in the correct page I try to
>> invalidate the corresponding TLB entry using the following assembly sequence:
>>
>> dsb ish
>> tlbi vaae1is, x0
>> dsb sy
>
> Do you have a repro case you can give us ?
> Does your setup involve SMP, or is this all on a single CPU ?
I had started on writing an explicit test case for all of this in:
https://github.com/stsquad/kvm-unit-tests/blob/712eb3a287df24cdeff00ef966d68aef6ff2b8eb/arm/tlbflush-data.c
but it's been a while and I need to debug what I was thinking when I
wrote it. However if we can get a test case for kvm-unit-tests that
would be great.
>
>> Unfortunately this does not seem to have any immediate effect, as
>> upon returning back to the source of the exception I immediately hit
>> the same Data Abort. This cycle of receiving a Data Abort and then
>> updating the mapping continues for 100s of times, until the TLB
>> finally updates to the correct mapping.
>
> Note that the architecture says that the DSB will guarantee the
> TLB maintenance operation to be finished for *other* processors,
> but that if you want to guarantee it to be finished for the
> processor which executed the TLBI then you must do a DSB followed
> by a "context synchronization event", eg a ISB insn, or return
> from exception. (See the v8 Arm ARM DDI0487G.b page D5-2833.)
> It sounds from your description as if a return-from-exception
> is done on the CPU that executed the TLBI, though...
>
> -- PMM
--
Alex Bennée