<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/arch/s390/kernel/head.S, branch linux-4.7.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>s390/facilities: make use of generated facility list</title>
<updated>2015-12-18T13:59:21+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2015-11-24T11:47:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0358ecf7327f0cb206b14138353e1cbe612c5d64'/>
<id>0358ecf7327f0cb206b14138353e1cbe612c5d64</id>
<content type='text'>
Change head.S to make use of the generated facility list.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Change head.S to make use of the generated facility list.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/facilities: always use lowcore's stfle field for storing facility bits</title>
<updated>2015-12-18T13:59:19+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2015-11-24T11:33:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=76cdd44c2e56ffabc297494c090c6babc8985998'/>
<id>76cdd44c2e56ffabc297494c090c6babc8985998</id>
<content type='text'>
head.s contains an stfle instruction which stores it result at the
storage location that is assigned to the stfl instruction.

This is currently no problem, since we only care about one double
word. However if the number of double words in the ALS bitfield grows
the current code is not very stable.

E.g. before issuing the stfle command the memory to which it stores
must be cleared, since the instruction may or may not clear memory
contents where no bits are set.

In order to simplify the code a bit always use the storage location
that we reserved for the stfle result.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
head.s contains an stfle instruction which stores it result at the
storage location that is assigned to the stfl instruction.

This is currently no problem, since we only care about one double
word. However if the number of double words in the ALS bitfield grows
the current code is not very stable.

E.g. before issuing the stfle command the memory to which it stores
must be cleared, since the instruction may or may not clear memory
contents where no bits are set.

In order to simplify the code a bit always use the storage location
that we reserved for the stfle result.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/facilities: use stfl mnemonic instead of insn magic</title>
<updated>2015-12-18T13:59:18+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2015-11-24T11:18:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9552a66fe622ed53b87278a90917a37a5245e68a'/>
<id>9552a66fe622ed53b87278a90917a37a5245e68a</id>
<content type='text'>
Now that 31 bit support is gone, the assembler always knows about the
stfl instruction. Therefore lets use a readable mnemonic.  Also remove
the not needed extable entry for the inline assembly and fix the
output constraint.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Reviewed-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now that 31 bit support is gone, the assembler always knows about the
stfl instruction. Therefore lets use a readable mnemonic.  Also remove
the not needed extable entry for the inline assembly and fix the
output constraint.

Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Reviewed-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390: remove SALIPL loader</title>
<updated>2015-11-16T11:51:11+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2015-11-13T13:17:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f52c74fee95f1f4dd2bc1c75e016d849150eb2de'/>
<id>f52c74fee95f1f4dd2bc1c75e016d849150eb2de</id>
<content type='text'>
There is no known user, therefore remove the code.

Acked-by: Rob Van Der Heij &lt;robvdheij@nl.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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There is no known user, therefore remove the code.

Acked-by: Rob Van Der Heij &lt;robvdheij@nl.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;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/head: fix error message on unsupported hardware</title>
<updated>2015-11-09T08:10:47+00:00</updated>
<author>
<name>Sascha Silbe</name>
<email>silbe@linux.vnet.ibm.com</email>
</author>
<published>2015-11-04T12:32:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c6eafbf9903c4283ba146098ad54240a24ffbeb1'/>
<id>c6eafbf9903c4283ba146098ad54240a24ffbeb1</id>
<content type='text'>
startup calls the C function _sclp_print_early() if the machine we're
running on is not supported by the kernel. sclp.c is getting built
with -m64, so _sclp_print_early() expects the zSeries ELF ABI to be
used.

We previously called _sclp_print_early() using the S/390 ELF ABI, with
a stack frame size of 96 bytes and while being in 31-bit address
mode. This caused _sclp_wait_int() (called indirectly from
_sclp_print_early()) to jump to an undefined address. While
_sclp_wait_int() contained some code to deal with being called in
31-bit addressing mode, it didn't quite work. While fixing this is
possible, the code would still only work by chance and could break any
time.

Ensure compliance with the zSeries ELF ABI by switching to 64-bit
addressing mode early and using a minimum stack frame size of 160
bytes.

Signed-off-by: Sascha Silbe &lt;silbe@linux.vnet.ibm.com&gt;
Acked-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
startup calls the C function _sclp_print_early() if the machine we're
running on is not supported by the kernel. sclp.c is getting built
with -m64, so _sclp_print_early() expects the zSeries ELF ABI to be
used.

We previously called _sclp_print_early() using the S/390 ELF ABI, with
a stack frame size of 96 bytes and while being in 31-bit address
mode. This caused _sclp_wait_int() (called indirectly from
_sclp_print_early()) to jump to an undefined address. While
_sclp_wait_int() contained some code to deal with being called in
31-bit addressing mode, it didn't quite work. While fixing this is
possible, the code would still only work by chance and could break any
time.

Ensure compliance with the zSeries ELF ABI by switching to 64-bit
addressing mode early and using a minimum stack frame size of 160
bytes.

Signed-off-by: Sascha Silbe &lt;silbe@linux.vnet.ibm.com&gt;
Acked-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<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.tavy.me/linux-stable.git/commit/?id=a69db2f6ad69157cace810971f19cb5aec9956b1'/>
<id>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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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;
</pre>
</div>
</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.tavy.me/linux-stable.git/commit/?id=22362a0e23182d230527a5add690b4027860d7d3'/>
<id>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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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;
</pre>
</div>
</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.tavy.me/linux-stable.git/commit/?id=5a79859ae0f35d25c67a03e82bf0c80592f16a39'/>
<id>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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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;
</pre>
</div>
</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.tavy.me/linux-stable.git/commit/?id=f8b2dcbd9e6d1479b9b5a9e9e78bbaf783bde819'/>
<id>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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Allow to generate code that only runs on z13 machines.

Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</pre>
</div>
</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.tavy.me/linux-stable.git/commit/?id=b881dcfbf7fd89b2be801843b060b9ad77cc77e7'/>
<id>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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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;
</pre>
</div>
</content>
</entry>
</feed>
