<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/arch/s390/kernel/head.S, branch dev-4.3</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.3</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.3'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2015-08-19T08:03:34+00:00</updated>
<entry>
<title>s390/facilities: remove transactional-execution bits</title>
<updated>2015-08-19T08:03:34+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2015-08-13T10:27:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a69db2f6ad69157cace810971f19cb5aec9956b1'/>
<id>urn:sha1:a69db2f6ad69157cace810971f19cb5aec9956b1</id>
<content type='text'>
Remove the two facility bits

50 - constrained transactional-execution facility
74 - transactional-execution facility

from the required facilities if the kernel is built with -march=zEC12.

E.g. z/VM 6.3 doesn't virtualize the TX facility yet. Therefore a kernel
built with -march=zEC12 and ipl'ed on a zEC12 machine as a z/VM 6.3 guest
will emit a message about the missing facilities and stop working.

The kernel however doesn't make use of the TX facility, therefore remove
the two TX related facility bits and fix this unpleasant behavior.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Reviewed-by: David Hildenbrand &lt;dahi@linux.vnet.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/sclp: convert early sclp console code to C</title>
<updated>2015-07-29T07:11:39+00:00</updated>
<author>
<name>Martin Schwidefsky</name>
<email>schwidefsky@de.ibm.com</email>
</author>
<published>2015-07-08T08:20:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=22362a0e23182d230527a5add690b4027860d7d3'/>
<id>urn:sha1:22362a0e23182d230527a5add690b4027860d7d3</id>
<content type='text'>
The 31-bit assembler code for the early sclp console is error
prone as git commit fde24b54d976cc123506695c17db01438a11b673
"s390/sclp: clear upper register halves in _sclp_print_early"
has shown.

Convert the assembler code to C.

Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390: remove 31 bit support</title>
<updated>2015-03-25T10:49:33+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2015-02-12T12:08:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=5a79859ae0f35d25c67a03e82bf0c80592f16a39'/>
<id>urn:sha1:5a79859ae0f35d25c67a03e82bf0c80592f16a39</id>
<content type='text'>
Remove the 31 bit support in order to reduce maintenance cost and
effectively remove dead code. Since a couple of years there is no
distribution left that comes with a 31 bit kernel.

The 31 bit kernel also has been broken since more than a year before
anybody noticed. In addition I added a removal warning to the kernel
shown at ipl for 5 minutes: a960062e5826 ("s390: add 31 bit warning
message") which let everybody know about the plan to remove 31 bit
code. We didn't get any response.

Given that the last 31 bit only machine was introduced in 1999 let's
remove the code.
Anybody with 31 bit user space code can still use the compat mode.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390: add z13 code generation support</title>
<updated>2015-01-22T11:15:57+00:00</updated>
<author>
<name>Martin Schwidefsky</name>
<email>schwidefsky@de.ibm.com</email>
</author>
<published>2015-01-14T16:50:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=f8b2dcbd9e6d1479b9b5a9e9e78bbaf783bde819'/>
<id>urn:sha1:f8b2dcbd9e6d1479b9b5a9e9e78bbaf783bde819</id>
<content type='text'>
Allow to generate code that only runs on z13 machines.

Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/head.s: use zero as address for stfl</title>
<updated>2014-09-25T08:52:06+00:00</updated>
<author>
<name>Christian Borntraeger</name>
<email>borntraeger@de.ibm.com</email>
</author>
<published>2014-09-19T13:46:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b881dcfbf7fd89b2be801843b060b9ad77cc77e7'/>
<id>urn:sha1:b881dcfbf7fd89b2be801843b060b9ad77cc77e7</id>
<content type='text'>
The architecture suggests to use address 0 as parameter for stfl,
to allow for future extensions. Using __LC_STFL_FAC_LIST (0x200)
shows which address is used, but might be not future proof.

Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390: require mvcos facility, not tod clock steering facility</title>
<updated>2014-07-16T08:48:09+00:00</updated>
<author>
<name>David Hildenbrand</name>
<email>dahi@linux.vnet.ibm.com</email>
</author>
<published>2014-06-18T10:32:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=4a36b44c77515ca1ad799577d3f9e2fa4d68bffa'/>
<id>urn:sha1:4a36b44c77515ca1ad799577d3f9e2fa4d68bffa</id>
<content type='text'>
Inlined uaccess functions require the mvcos facility (bit 27), not the tod
clock steering facility (bit 28) for z10 and newer machines.

Signed-off-by: David Hildenbrand &lt;dahi@linux.vnet.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/facilities: remove extract-cpu-time facility check</title>
<updated>2014-05-28T08:38:50+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2014-05-27T07:52:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=6eb58d9bc113b9d3f97b710d9e5c1bc4f5044768'/>
<id>urn:sha1:6eb58d9bc113b9d3f97b710d9e5c1bc4f5044768</id>
<content type='text'>
Remove the check for the extract-cpu-time facility within early startup
code. Both kernel and user space work if the facility is not installed.

The vdso code has a run time check if the ectg is available. Besides that
there is no known user.

Reported-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Acked-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390: require mvcos facility for z10 and newer machines</title>
<updated>2014-05-27T08:26:05+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2014-05-27T07:40:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=0c91f98e28d2d123037ff59366ab7e1bca3e1276'/>
<id>urn:sha1:0c91f98e28d2d123037ff59366ab7e1bca3e1276</id>
<content type='text'>
With inlined uaccess functions we always need the mvcos facility.
Checking at each inline place if mvcos is available would make the
inlining of get_user/put_user pointless.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/bitops: optimize set_bit() for constant values</title>
<updated>2013-10-24T15:16:53+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2013-09-17T07:48:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=4ae803253e4649803dc6e972bb5e59fc107cf474'/>
<id>urn:sha1:4ae803253e4649803dc6e972bb5e59fc107cf474</id>
<content type='text'>
Since zEC12 we have the interlocked-access facility 2 which allows to
use the instructions ni/oi/xi to update a single byte in storage with
compare-and-swap semantics.
So change set_bit(), clear_bit() and change_bit() to generate such code
instead of a compare-and-swap loop (or using the load-and-* instruction
family), if possible.
This reduces the text segment by yet another 8KB (defconfig).

Alternatively the long displacement variants niy/oiy/xiy could have
been used, but the extended displacement field is usually not needed
and therefore would only increase the size of the text segment again.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390: add zEC12 code generation support</title>
<updated>2012-11-23T10:14:31+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2012-11-13T08:26:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=991c15053a3fc209d76f03c73d4f0621025c9452'/>
<id>urn:sha1:991c15053a3fc209d76f03c73d4f0621025c9452</id>
<content type='text'>
Allow to generate code that only runs on zEC12 machines.

Also add a check which prevents the kernel to run on machines which
do not have any of the following new facilities installed:

- (48) decimal-floating-point zoned-conversion
- (49) execution-hint
- (49) load-and-trap
- (49) miscellaneous-instruction-extensions
- (49) processor-assist
- (50) constrained transactional-execution
- (73) transactional-execution

48, 49, 50 and 73 are the bit numbers of the facility indications for
each of the required facilities.

Note that we assume that user-space gets compiled with the same
compiler options, therefore we also test for a dfp facility even
if the kernel doesn't make use of it.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
</content>
</entry>
</feed>
