Skip site navigation (1)Skip section navigation (2)
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>