Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Feb 2013 14:39:04 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Andrew Turner <andrew@fubar.geek.nz>
Cc:        freebsd-current@freebsd.org, Olivier Houchard <cognet@ci0.org>, Svatopluk Kraus <onwahe@gmail.com>
Subject:   Re: ARM pcpu changes, was Re: [patch] i386 pmap sysmaps_pcpu[] atomic access
Message-ID:  <20130226123904.GO2454@kib.kiev.ua>
In-Reply-To: <20130226210651.580c46a7@bender>
References:  <CAFHCsPUVTM9jfrnzY72YsPszLWkg-UaJcycTR4xXcS%2BfPzS1Vg@mail.gmail.com> <201302201022.29294.jhb@freebsd.org> <CAFHCsPXEDiaKSkHNbycs%2B1DKkL7BcYJBk5eN%2BKpsLY8B%2B-u5gQ@mail.gmail.com> <201302211043.49906.jhb@freebsd.org> <20130225190920.1b7d348d@bender> <20130225124747.GA21027@ci0.org> <20130226210651.580c46a7@bender>

next in thread | previous in thread | raw e-mail | index | archive | help

--ECcIMtargrIi2fbc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 26, 2013 at 09:06:51PM +1300, Andrew Turner wrote:
> Does anyone know if it is only curthread that needs to be atomic? If so
> this should work. Reading the cpuid from the system currently is a
> single instruction, however it appears the code will need to be reworked
> for use with multiple levels of affinity, for example when there
> are clusters of cores the current code will number two cores on
> different clusters with the same id.
>=20
> I don't think we need to use ldrex/strex to read/write the values, my
> understanding is the rest should be safe to access without atomic
> functions.

I read about ARM architecture some time ago. What I am saying below is not
a proposal, but rather a way for me to learn more about the architecture.

=46rom my reading of the docs, ARM has the shadow registers, in particular,
the r13 (stack pointer) is shadowed for all privileged modes. Is the shadow
used by our kernel, is it correctly restored on the context switch ?

If yes, you can easily recover the pcb address from the current sp,
without accessing any coprocessor registers, and even without any
assignment of the global register for curthread (which needs to be
done at the kernel entry). Just align the stack
start on the 2*PAGE_SIZE boundary (like it is already done for MIPS),
and do the mask operation on the sp value to get the end of pcb.
This is atomic and context-switch safe.

pcb us already per-thread, and can store the thread pointer.
More, you can store the curcpu or cpuid pointer into pcb too,
and update it on the context switch.

amd64 has an architecturally-defined special register (k)gsbase, which
effectively must be correctly initialized at each kernel entry, and
restored on the return to usermode. Since the initialization on entry
and restoration on exit is not atomic wrt the entry/exit itself, amd64
periodically gets a bugs which cause kernel running with user gsbase.
This is the fatal bug, destroying the kernel structures and allowing the
CPU privilege mode switch for normal user.

Using the shadow registers for this purpose eliminate the whole source
of the bugs.

--ECcIMtargrIi2fbc
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iQIcBAEBAgAGBQJRLKznAAoJEJDCuSvBvK1Bm8AP/iYSJSEjXFFSYJRQNrbqdBoF
1eG3YiNNRfy9Kx9AprbX9k80wAQ/GjcfsUJQqDZvooqnW2tSMD2vp7DboGAWiIrH
CPcwpZ0P8yXBzn3pnKwnThH8/S5jtRnlvAOls2S0Z3pLxn/XAgeTase8jzOinndF
WirQ0igP833EWqSXK5JHwOln96+zvH/3VYRYvSAk931xa1JY3nWMEGB7il/afwRH
bpykijqpAoakVZccC0GFxFv+hIKhJDjFIzh2ds4QuDKyErzV57l48m0r2IHbPN8H
jXCXgO5N0gjnLAQT3fAAVK0jFgKg9KlLH2EPz7QSfjnG/Z/dRhb41HOze6AP3yU9
+AjpLeSHRj51NcQwydbLg2RrQp+UdeRgPiidYe83c7XSYK4KJJWwRNS2+Xq724gY
NWYE6IbOL3v3PIVyPo7OvRz2D7CyhAwevsrhusnm7F0q2be1wzmcbartTvDjnAcv
DJ7jibwqsqo2ewgBWiHrWSIDkbHEvSEhh2kWRKHPSH8TP7syXSK+IuP2ntxQQhMm
Nqpc4R8+YlaXCJNgqXuzlWoXfiYVr9AsFfqI7ppAtTYPI6ZRagDOdXVP4ySUYVzb
Tmm/pWRUCeMQAlHxrpELlrQM3STGBDerQ7QDayONHhpe2ZsVsqXahkQY/BY3Clwr
s+4cdWwUpBVL2fbOSzr4
=TI8c
-----END PGP SIGNATURE-----

--ECcIMtargrIi2fbc--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130226123904.GO2454>