Tue, Jun 21
Dec 19 2021
OK to MFC it to stable/13?
Nov 18 2021
Jul 24 2021
Jul 10 2021
Oof, that erratum; thanks for the heads up. I guess that means there should be some mechanism to replace (other uses of) sfence_vma_page with sfence_vma on effected chips? I think specifically for this case, though, it's fine: the ITLB may still fill with the old entry before this sfence.vma, but pmap_fault only changes A/D here. I suppose there could be an extra fault delivered from caching an A-clear PTE (if the load is done now by some very prognosticative speculation, say) despite that pmap_fault just set it, and I imagine the ITLB doesn't care about D at all. This extra fault will land us here again and cause another sfence.vma and even if the ITLB simultaneously refills the PTE about to be sfence.vma-ed, it will definitely see the A-set PTE from the last go around. That is, I don't think this makes anything worse.
Jul 9 2021
And how does this interact with the fact that we don't invalidate on promotion? I believe sfence.vma with an address is only required to invalidate leaves, but TLBs can cache non-leaves, so we could still return, have the processor use the stale cached non-superpage L2 entry, find the old leaves that are still around (because we keep them around) and reuse those?
Although perhaps that's fine if this is in the _fault_ path?
This will hit SiFive FU740 erratum CIP-1200 (https://sifive.cdn.prismic.io/sifive/167a1a56-03f4-4615-a79e-b2a86153148f_FU740_errata_20210205.pdf).
Jun 25 2021
Jun 24 2021
Thanks, this fell off my radar.
Jun 22 2021
Jun 4 2021
Jun 2 2021
Thanks to @markj for the explanation; this is an incorrect fix.
May 30 2021
Yes, there is no way to detect what hardware does short of trying and seeing (the spec mandates all harts must always do dirty tracking, or all harts must never, so it's an easy test if you really want to). QEMU currently implements hardware dirty tracking, with no knob to turn it off. Depending on how it's configured, an FPGA implementation we use also does.
The essential difference here is that riscv's pmap_promote_l2() assumes that PTE_D is always set by software, i.e., no hardware management of the dirty bit. We should possibly fix that instead.
Well, for whatever it's worth, the reproducer seems not to panic on amd64, which is a little surprising as I don't see any special handling for setting PG_M on !VPO_UNMANAGED, PG_RW, psind=1 pages in pmap_enter(), and I'd have thought the MI layers were doing the same thing on both.
Have you tried running this on arm64? Its pmap_demote_l2_locked has a similar:
KASSERT((oldl2 & (ATTR_S1_AP_RW_BIT | ATTR_SW_DBM)) != (ATTR_S1_AP(ATTR_S1_AP_RO) | ATTR_SW_DBM), ("pmap_demote_l2: L2 entry is writeable but not dirty"));
Can we include the test program as a regression test in tests/sys? No need to rewrite it in ATF, keeping it as a plain C executable seems fine to me.
Apr 27 2021
Seems fine to me
Mar 25 2021
Mar 3 2021
Jan 19 2021
Oct 17 2020
Oct 13 2020
Oct 9 2020
Oct 8 2020
Renamed macro as per mhorne's feedback
Sep 30 2020
Aug 18 2020
Approved by: philip, kp (mentors)