From owner-freebsd-mips@freebsd.org Sun Nov 13 15:51:26 2016 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AEA8BC3F831 for ; Sun, 13 Nov 2016 15:51:26 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 701D21DB4 for ; Sun, 13 Nov 2016 15:51:26 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: by mail-it0-x235.google.com with SMTP id c20so33753742itb.0 for ; Sun, 13 Nov 2016 07:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=clockworksquid.com; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=ilStorIxegHUnJ/tdviBMRRMv1A6rQRnI2a46P/cF48=; b=LCiQ/j9G/YUDQJR1rbPWZ3m4HOmehkONm3pg0cVR2WSN2+RkxH8lrjDm5QKt00be0j 4fxLluE0sC6UsorQFb9D6npkSscRITyxHnqk0o8EsAaeItzRi8UfP8qv/BLKMDJLNbU8 uD9o/2Yy4vlQu/xx4/twUP8Bsh0LhesoMjLAw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=ilStorIxegHUnJ/tdviBMRRMv1A6rQRnI2a46P/cF48=; b=CPFCPR4JQIoZlp+NkO8SpF2N/JZsiqRh+G4ZXrN5Bf9Y5ggH1TrlSgCuit1Txr8k7q 7XTYXxO7DHaLdc5VaS/44v8NQzH87SLHVj1yNA9Jc2LLLkqOflx2L+IF6WDjtQ1UKw7a 2CNcRye/q6gUcvUwfidNTspV2qXsGkaZBKJ3vROILmSv1Cvyfi8xN2coCRZLo8po5Pw8 VmVLN15+0Tyty42SMw1ONcAZoNyNqQQR3phsSgVmexIiWUwc8ssOm41CkjsagEuLdYT1 x7gdkh7s7G1PhEOSnLJgloRY+U428oqUOU8dsrKPHZMm0UvViws8Bh7sMf6lR0w3yNuY iW3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=ilStorIxegHUnJ/tdviBMRRMv1A6rQRnI2a46P/cF48=; b=YiEryrmhUftyfi3cntGMS0Zv81wp1+eUcPpJENPc239KWo0I/eCtiQX4Cbf7GlyBbg YTRMfTcegf17Z3Uk0DyhJXjZ0hqvjjv70UszAyXpuCTG0RMs3Da0hUgCp2ysG3UBY+3E p0ZCxKSiitNILKc0MStOxslIDP0p5atO6UGflmhAYffHbK2cMu4DlS+wsI2zGuc8Taor CnqZ3D65KO+Tv/TAo7U3MkSHlevI7sMtYz49agH+po5JWvjad/y8Ibk5ZN6cpYRQgeHY xZ9D0Zq7wx+pzfzw9Nxy87TebNRDt/BxI4kP3M30EtwBKiEkCVdV9TcCflWViLS85S52 EM/A== X-Gm-Message-State: ABUngveD+VvyBeDb8Txlul3EJpqzLUw6MHCmrnZhMYcBW593UrhBi8COrmyQvAP038N3IYt/LE7/ZLCy7K+pzg== X-Received: by 10.107.59.9 with SMTP id i9mr23347047ioa.176.1479052285626; Sun, 13 Nov 2016 07:51:25 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.79.141.88 with HTTP; Sun, 13 Nov 2016 07:51:05 -0800 (PST) In-Reply-To: <71C512CD-0FB6-40D8-B46C-30467A245693@bsdimp.com> References: <201610191109.u9JB9TTC002727@repo.freebsd.org> <20161113065851.GD54029@kib.kiev.ua> <20161113071911.GF54029@kib.kiev.ua> <20161113075557.GH54029@kib.kiev.ua> <71C512CD-0FB6-40D8-B46C-30467A245693@bsdimp.com> From: Juli Mallett Date: Sun, 13 Nov 2016 07:51:05 -0800 X-Google-Sender-Auth: DuB9-riFV-zkfLGaGs2PpDDjW7s Message-ID: Subject: Re: svn commit: r307626 - head/sys/ufs/ffs To: Warner Losh Cc: Konstantin Belousov , Warner Losh , Adrian Chadd , "freebsd-mips@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 15:51:26 -0000 On Sun, Nov 13, 2016 at 12:13 AM, Warner Losh 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.