From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSzfc-0006Cq-Fq for qemu-devel@nongnu.org; Fri, 29 Jul 2016 00:45:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bSzfa-0001YH-Hz for qemu-devel@nongnu.org; Fri, 29 Jul 2016 00:45:11 -0400 Message-ID: <1469767495.5978.249.camel@kernel.crashing.org> From: Benjamin Herrenschmidt Date: Fri, 29 Jul 2016 14:44:55 +1000 In-Reply-To: <579ad8bd.8481620a.89e78.f1ce@mx.google.com> References: <579ad8bd.8481620a.89e78.f1ce@mx.google.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 28/32] ppc: Avoid double translation for lvx/lvxl/stvx/stvxl List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: David Gibson , qemu-devel , qemu-ppc@nongnu.org On Fri, 2016-07-29 at 09:46 +0530, Richard Henderson wrote: >=C2=A0 > But that doesn't yet make the leap to 128-bit types in tcg. > I was going to raise that topic during the 2.8 cycle, since as a > consequence I want to drop support for 32-bit hosts, at least for 64- > bit guests, and maybe entirely. I wonder (or is it too chancy ?) if it's worthwhile having a TCG ops that in effect does a translate and returns a host pointer... That or a slightly more convoluted way of asking the backend to produce a series of load/stores. We can provide the element size (so it can do byteswap) and the base reg. Maybe a stride too. We can have a default impl that turns it into a loop of existing load/stores and smart backends can check for page boundaries and limit the translations. That would allow a much more efficient implementation for example of ppc store/load multiplem which are heavily used by 32-bit guest code for example. Cheers, Ben.