Hi Jan,
On Wed, Jul 20, 2016 at 10:05:01AM +0100, Marc Zyngier wrote:
> On 20/07/16 07:09, Jan Kiszka wrote:
> > I've two questions for a while now:
> >
> > - Are dcache flushes consistently required, or does the MMU snoop
> > caches when doing stage-2 translations? We could easily add a
> > DCCIMVAC for the modified entries, but I saw KVM flushing even
> > page-wise.
>
> Two things:
> - ARMv8 guarantees that the page table walker can snoop the caches,
> while we don't have that guarantee on ARMv7, so you need to clean the
> cache to the PoC (if memory serves well).
For ARMv8-A, as Marc said, walks are guaranteed to be coherent, for both
AArch64 and AArch32. For ARMv7-A, walks are guaranteed to be coherent in
the presence of the virtualization extensions.
In general for ARMv7-A, walks are only coherent (i.e. snoop all
data/unified caches) if ID_MMFR3[23:20] ("Coherent Walk") contains
0b0001. See the latest ARM ARM, ARM DDI 0406C.c, section B4.1.92.
In other cases, it is necessary to clean to the PoU.
The multiprocessing extensions mandate this coherency, per ARM DDI
0406C.c, section B3.3.1 and ARM DDI 0406C.c, section B3.10.1. The
virtualization extensions mandate the multiprocessing extensions, per
ARM DDI 0406C.c, section B1.7. Thus, in any ARMv7-A implementation with
virtualization, page table walks must be coherent.
In the appendices there are example sequences with further
clarification. For ARMv8-A See ARM DDI 0487A.j, section K10.5.3. For
ARMv7-A see ARM DDI 0406C.c, section D7.5.3.
> - KVM cleans the cache to the PoC when mapping a page if the guest
> doesn't have its own caches enabled. Otherwise you will happily run with
> junk while the data sits pretty in the cache. (see my presentation at
> KF'15).
>
> > - Under which conditions do we need to apply [1] ("break before make")
> > in our setup? Is it really required to first write an invalid
> > PTE/PMD/etc., then flush TLBs on all affected CPUs, and only then
> > write the new entries?
>
> BBM is always required if you're changing the output address of a page
> table entry. No ifs, no buts. For a very long time, we thought we could
> get away without it, but as CPUs get much more aggressive at partial TLB
> caching, we've seen all kind of weird issues, and Mark can rant about it
> for hours (I'm sure he will once he reads this email).
I'll try to resist ;)
There are a couple of other cases (e.g. memory type and cacheability)
too, so it's best to consult the ARM ARM.
For ARMv8-A see ARM DDI 0487A.j, section D4.7.1. For ARMv7-A see ARM DDI
0406C.c, section B3.10.1. In both cases scroll down to "Using
break-before-make when updating translation table entries".
To the best of my knowledge, an "output address" can be the value of a
page, block/section, or table entry, so changing intermediate levels of
table requires BBM, even if the end-to-end translation would happen to
remain equivalent.
> > so that we can document this in the code)!
>
> Now you're asking too much. I've only had one coffee, and the idea of
> trying to navigate the ARM ARM that early makes me feel slightly
> nauseous. Or maybe that the beer from last night. Or the weather.
Luckily I remember a few key phrases to grep for. ;)
Hopefully the references above are of use!
Thanks,
Mark.
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
