Date: Sun, 13 Nov 2016 07:51:05 -0800 From: Juli Mallett <jmallett@freebsd.org> To: Warner Losh <wlosh@bsdimp.com> Cc: Konstantin Belousov <kostikbel@gmail.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: <CACVs6=_zmjJhMzmyFGJGHK1RAguQ_fZUcd94ZEmVEnTXBiOSdQ@mail.gmail.com> In-Reply-To: <71C512CD-0FB6-40D8-B46C-30467A245693@bsdimp.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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 13, 2016 at 12:13 AM, Warner Losh <wlosh@bsdimp.com> wrote: > [[ Moved to freebsd-mips and cc=E2=80=99d to Juli ]] > > That=E2=80=99s a very good question. Unfortunately my memory here fails m= e. I have a recollection that the various cache flushing that we do in the = map ensures that we don=E2=80=99t hit a problem. However, I couldn=E2=80=99= 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= =E2=80=99t have thought it causes the fault in question, but MIPS errors ca= n manifest in strange ways, so perhaps you are correct. I don=E2=80=99t get= how the fault address is 0 though from that scenario. Maybe Adrian can rec= all. 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. 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. Thanks, Juli.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACVs6=_zmjJhMzmyFGJGHK1RAguQ_fZUcd94ZEmVEnTXBiOSdQ>