Date: Fri, 22 Aug 2014 22:01:40 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Craig Butler <craig001@lerwick.hopto.org> Cc: sparc64@freebsd.org Subject: Re: svn commit: r270201 - in head/sys: powerpc/include sys Message-ID: <20140822190140.GQ2737@kib.kiev.ua> In-Reply-To: <1408733192.4056.5.camel@atlas.lerwick.hopto.org> References: <201408200802.s7K82cJ6059609@svn.freebsd.org> <20140820082700.GY2737@kib.kiev.ua> <1408733192.4056.5.camel@atlas.lerwick.hopto.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Fcn+O7u6afXSKWdN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 22, 2014 at 07:46:32PM +0100, Craig Butler wrote: > On Wed, 2014-08-20 at 11:27 +0300, Konstantin Belousov wrote: > > On Wed, Aug 20, 2014 at 08:02:38AM +0000, Konstantin Belousov wrote: > > > Author: kib > > > Date: Wed Aug 20 08:02:38 2014 > > > New Revision: 270201 > > > URL: http://svnweb.freebsd.org/changeset/base/270201 > > >=20 > > > Log: > > > Add arch-specific macro SFBUF_PHYS_DMAP(), which should translate t= he > > > physical address of the page to direct map address, in case > > > SFBUF_OPTIONAL_DIRECT_MAP returns true. The case of PowerPC AIM > > > 64bit, where the page physical address is identical to the direct m= ap > > > address, is accidental. > > Real use of this interposer is for sparc64 machines which can use direct > > map due to usable cache implementation. > >=20 > > Could someone with the machine identified as SPARC64V test the following > > patch ? Just booting multiuser should be enough. > >=20 > > diff --git a/sys/sparc64/include/vmparam.h b/sys/sparc64/include/vmpara= m.h > > index 8e7d76c..c2f30c3 100644 > > --- a/sys/sparc64/include/vmparam.h > > +++ b/sys/sparc64/include/vmparam.h > > @@ -241,5 +241,8 @@ extern vm_offset_t vm_max_kernel_address; > > =20 > > #define SFBUF > > #define SFBUF_MAP > > +#define SFBUF_OPTIONAL_DIRECT_MAP dcache_color_ignore > > +#include <machine/tlb.h> > > +#define SFBUF_PHYS_DMAP(x) TLB_PHYS_TO_DIRECT(x) > > =20 > > #endif /* !_MACHINE_VMPARAM_H_ */ >=20 > What machines are identified as SPARC64V ?? our collection only > identifies as sparc64. SPARC64V are Zeus cores from Fujitsu. https://en.wikipedia.org/wiki/SPARC64_V FWIW, I find it strange that later cores are not marked as having the unaliasing tagging. >=20 > I think the sun4v code got sin binned, AFAIK the sun4u identifies as > just plain sparc64. sun4v is the platform name, not the CPU microarchitecture. I believe that Zeus are sun4u. --Fcn+O7u6afXSKWdN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT95OUAAoJEJDCuSvBvK1BWssP/0uNcVwe40ZjBzYO+iMGn8+j H7pyg6wDcD8HstRLIuc+vv3nuE5j0zne4nqVG3DNEjhn8h1FLZvCP35JAq1dyKI+ 7q95e8lbPGMjIdzQXSeOzFL9PApHqG288J/D3WpvyCymzZHDvgSIUKHs9AhidYdb ZJBxCKZvL8TPP/99SC5LxExGNVTP3NlzknTQWpUiUt3okGPyNpK/t5SN+qd0dBQF Cuq7eFFr3IenmDRjxMbvV2ZL2u6Dldi7K33spJQZpKUPpqPbIdA+0tdo9ryHPwRW fpwZeHnVeYrjPDFt1T3YSMXL8pWl7DBQcRDbs63jdmirNX9i1Vn4wB7SDkVKkOQJ HQlOEUeNS5BfG3OEdGyrXOFygUgxsjU3gVuOlacXZs8P+nfgQRyTZAoYmmGo82Js MwMJYTgQxBf54VWwxC2Ckb/Mm2xD2JVz419pmaT+3VXQM2YzF1aMRuHMtro6JNyA JggwFG5WptH7H6IUCLsoUVL+WfjQy1Fgp28QJ0O57cz+MyjNATcHZUn/kMJc/gBB caJbr/I3fYgG+ZQuaRAsbUdF4Xu7HofQwd+brB3wyL1PUg4W6hnH3CBiatGZmzjr MPApqkx14djxI2jcH2BGN9Wq3NLUUHGxs9yu1CbIpXqf1d8SVV6OEbpZQMzI/XQT 2o5KQcFEwfYqzIUan3CW =PQ/a -----END PGP SIGNATURE----- --Fcn+O7u6afXSKWdN--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140822190140.GQ2737>