From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59698) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aON5P-0001JC-QH for qemu-devel@nongnu.org; Wed, 27 Jan 2016 05:12:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aON5K-0005OK-FQ for qemu-devel@nongnu.org; Wed, 27 Jan 2016 05:12:27 -0500 Date: Wed, 27 Jan 2016 21:07:38 +1100 From: David Gibson Message-ID: <20160127100738.GL16692@voom.fritz.box> References: <1453698952-32092-1-git-send-email-david@gibson.dropbear.id.au> <1453698952-32092-4-git-send-email-david@gibson.dropbear.id.au> <56A6760B.2020300@suse.de> <20160127000414.GG16692@voom.fritz.box> <56A87289.6000200@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NZiXfHLGvOGtDZMn" Content-Disposition: inline In-Reply-To: <56A87289.6000200@redhat.com> Subject: Re: [Qemu-devel] [PATCH 03/10] target-ppc: Rework ppc_store_slb List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Huth Cc: lvivier@redhat.com, aik@ozlabs.ru, Alexander Graf , qemu-devel@nongnu.org, qemu-ppc@nongnu.org --NZiXfHLGvOGtDZMn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 27, 2016 at 08:32:25AM +0100, Thomas Huth wrote: > On 27.01.2016 01:04, David Gibson wrote: > > On Mon, Jan 25, 2016 at 08:22:51PM +0100, Alexander Graf wrote: > >> > >> > >> On 01/25/2016 06:15 AM, David Gibson wrote: > >>> ppc_store_slb updates the SLB for PPC cpus with 64-bit hash MMUs. > >>> Currently it takes two parameters, which contain values encoded as the > >>> register arguments to the slbmte instruction, one register contains t= he > >>> ESID portion of the SLBE and also the slot number, the other contains= the > >>> VSID portion of the SLBE. > >>> > >>> We're shortly going to want to do some SLB updates from other code wh= ere > >>> it is more convenient to supply the slot number and ESID separately, = so > >>> rework this function and its callers to work this way. > >>> > >>> As a bonus, this slightly simplifies the emulation of segment registe= rs for > >>> when running a 32-bit OS on a 64-bit CPU. > >>> > >>> Signed-off-by: David Gibson > >>> --- > >>> target-ppc/kvm.c | 2 +- > >>> target-ppc/mmu-hash64.c | 24 +++++++++++++----------- > >>> target-ppc/mmu-hash64.h | 3 ++- > >>> target-ppc/mmu_helper.c | 14 +++++--------- > >>> 4 files changed, 21 insertions(+), 22 deletions(-) > ... > >>> @@ -196,7 +198,7 @@ void helper_store_slb(CPUPPCState *env, target_ul= ong rb, target_ulong rs) > >>> { > >>> PowerPCCPU *cpu =3D ppc_env_get_cpu(env); > >>> - if (ppc_store_slb(cpu, rb, rs) < 0) { > >>> + if (ppc_store_slb(cpu, rb & 0xfff, rb & ~0xfff, rs) < 0) { > >> > >> This might truncate the esid to 32bits on 32bits hosts, no? Should be > >> 0xfffULL instead. > >=20 > > Good point, nice catch. >=20 > Are you sure that it is really needed? If I run the following test > program on my 64-bit system: >=20 > int main() > { > unsigned long long ll =3D -1ULL; > printf("%llx %llx\n", ll, ll & ~0xfff); > return 0; > } >=20 > Then I get this output: >=20 > ffffffffffffffff fffffffffffff000 >=20 > So it sounds like the value is sign-extended when it is cast to > 64-bit. Ah, yes. It would be promoted to s64 and sign extended before being promoted to u64. Still that's a pretty subtle detail to be relying on. =20 > However, if you respin this patch series anyway, then maybe better add > the ULL for clarity. Already done. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --NZiXfHLGvOGtDZMn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWqJbpAAoJEGw4ysog2bOS8KcP/1dI5/HThZY/NkoFE5q1U7ez FUHyuklGIz7tafvFn8ShANacblNzLV3GUqpdCIMthlQKEfqpN4oIdLZNda7e/yu6 zbC4CKKseyzODJBRHvG4BWOgoasFKAYkuha6TUPkSstr+KWcz11UqnpG7jyYVzyZ FFk8I2eQO9AVmfywXEuruSHJJJ/2C9p5kFb05jrsqwfgIjmG0h8HSr8iEmXsFYU1 9RlFyJw4pLJ7oUOV/caXUeKrunbiLyA8mPGelhBbe7KJ0Nb7hbYFc7Fh1y9s8u4n 69toUdkkjn68onV6V77euDLfsvhMsb/3EuHtxthi2avBVib3tshYOkZ3pDIHkTgD MlpOIq+lfmIrnNuZI8OF1DdlFcJPhKFQMW73HjZ+kpB8wHMMxw1sVQZRBr9/+YSx 5BPSd/9nOEUI8f1q3MeyWW9hlL4dF0tG8+mVt+IyeFEH7GMx8pSZMCDw/f3GiqgS WFPbE22lmeZndMYRx8vLaXz369avVYcZVKqAQPAZz5CBZxBdPNNsHqD+LQZWKopk 4XnJq+uNqRkUnI9BTKii2TFD06of7JzLX0epBYEa99bvdV/yOEndenoyqE9u+Q8G nyBlANxXrMKXjbdO9Y5FF5rZpJ5ZmHGexatkI/mrVDLLaXOJrH9mC9GgVUSoKeGH TNK5Vb+wgkZatUGEG2dJ =tu4F -----END PGP SIGNATURE----- --NZiXfHLGvOGtDZMn--