Date: Sun, 13 Nov 2016 18:15:48 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Juli Mallett <jmallett@freebsd.org> Cc: Warner Losh <wlosh@bsdimp.com>, Warner Losh <imp@bsdimp.com>, Adrian Chadd <adrian.chadd@gmail.com>, "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org> Subject: Re: svn commit: r307626 - head/sys/ufs/ffs Message-ID: <20161113161548.GK54029@kib.kiev.ua> In-Reply-To: <CACVs6=_zmjJhMzmyFGJGHK1RAguQ_fZUcd94ZEmVEnTXBiOSdQ@mail.gmail.com> References: <201610191109.u9JB9TTC002727@repo.freebsd.org> <CAJ-Vmom5rYe89m7bch4qoHHq3X2e67pPk_7G2aRGrjSPNp5mzg@mail.gmail.com> <20161113065851.GD54029@kib.kiev.ua> <CANCZdfreg9wD-2pdGtzgeO86BptSE4M7LnLFTC09K3RHyHR8cQ@mail.gmail.com> <20161113071911.GF54029@kib.kiev.ua> <CANCZdfpC6smeNSPKzpbX8aAnF8CZ%2BSEFQmQ74jqvWUVXrttM%2BQ@mail.gmail.com> <20161113075557.GH54029@kib.kiev.ua> <71C512CD-0FB6-40D8-B46C-30467A245693@bsdimp.com> <CACVs6=_zmjJhMzmyFGJGHK1RAguQ_fZUcd94ZEmVEnTXBiOSdQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 13, 2016 at 07:51:05AM -0800, Juli Mallett wrote:
> On Sun, Nov 13, 2016 at 12:13 AM, Warner Losh <wlosh@bsdimp.com> wrote:
> > [[ Moved to freebsd-mips and cc???d to Juli ]]
> >
> > That???s a very good question. Unfortunately my memory here fails me. I have a recollection that the various cache flushing that we do in the map ensures that we don???t hit a problem. However, I couldn???t construct a coherent answer to where this takes place after a brief look at the code. Multiple mappings will cause data corruption though. I wouldn???t have thought it causes the fault in question, but MIPS errors can manifest in strange ways, so perhaps you are correct. I don???t get how the fault address is 0 though from that scenario. Maybe Adrian can recall. Or Juli can help.
>
> As I recall, the "mips2" and Juniper code just punted on this, and the
> current in-tree code did likewise. In fact, we explicitly use
> aliasing in some places for short-term things through cached,
> direct-mapped operations, with probably less than the requisite cache
> ops to make VIPT processors work safely.
>
> There's also no set of cache ops you can put into pmap to make it safe
> in general; attempts to do so probably haven't understood the scope of
> the problem. We can end up with aliasing in the same process, so
> doing it only on pmap activate doesn't prevent aliased accesses. You
> could, if you want to really churn the TLB, allow only one active
> mapping at a time and go through a trap to manage the mappings of
> shared, cacheable pages. It's either that, or we have to, as Adrian
> suggested, either mappings to uncached when persistent aliasing
> occurs, or unshare those mappings, depending on whether the aliasing
> is an optimization or a requirement for correctness. The easier thing
> is probably to go through the PV mappings, and allow only one active
> PTE at a time, and to eat the cost of all those traps for aliased
> mappings, while remembering to be diligent about not allowing sharing
> without copious cache flushing in the cases in the kernel where we
> have temporary aliases using the direct map.
Sparc64 also has the aliasing issue, and AFAIR sparc64 pmap does allow
more than one mapping of the same page at conflicting ('differently
colored') addresses. But indeed, each mapping (not only the managed
mappings) are tracked, and all mappings are demoted to uncached if
conflict is created.
>
> It'd be neat to see this happen; I'm not sure who would really do it.
> It's tricky to get right. We may support other architectures that
> have complete or partial solutions to this, but I deliberately don't
> know about them. Stare at code dealing with VIPT ARM systems, or pmap
> on other BSDs that have sunk more effort into all the edge cases of
> VIPT MIPS systems.
For arm, only arm v4 pmap deals with VIPT aliasing. Arm v6 assumes that
the system is free from that bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161113161548.GK54029>