- 10 Jul, 2024 3 commits
-
-
Heiko Carstens authored
Use mvhi/mvghi for small constant values within the __atomic_set() inline assemblies. This avoids loading the specified value into a register. The size of the kernel image is reduced by ~1.2kb. Reviewed-by:
Juergen Christ <jchrist@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Heiko Carstens authored
Consistently use symbolic names in all atomic ops inline assemblies. Reviewed-by:
-
Sven Schnelle authored
Instead of setting up non-boot CPUs early in architecture code, only setup the cpu present mask and let the generic code handle cpu bringup. Signed-off-by:
Sven Schnelle <svens@linux.ibm.com> Signed-off-by:
-
- 02 Jul, 2024 3 commits
-
-
Heiko Carstens authored
Describe that some HWCAP bits are reserved to avoid that they will be used by accident. Suggested-by:
Stefan Liebler <stli@linux.ibm.com> Reviewed-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
-
Claudio Imbrenda authored
Make the crdte() and cspg() wrappers return a boolean to indicate success, like the other already existing "compare and swap" type of wrappers. Add documentation for those functions as well. Acked-by:
Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by:
-
Mete Durlu authored
s390 generates KOBJ_CHANGE uevents on CPUs whenever a topology update occurs. These uevents currently have no users and they are also not present on other architectures. As they are not necessary, remove these extra uevents. Suggested-by:
Mete Durlu <meted@linux.ibm.com> Signed-off-by:
-
- 01 Jul, 2024 3 commits
-
-
Peter Oberparleiter authored
Due to a bug in some firmware versions, Store Data requests might not get an event response in certain situations. As a result, the boot process will be blocked indefinitely. Fix this by introducing timeout handling for Store Data requests. In case a timeout occurs, the Store Data operation is halted and no data is retrieved from the SCLP facility. Note: A minority of installed systems rely on Store Data result for device auto-configuration. These systems will fail to boot in case of a Store Data timeout and will need to be switched to manual device configuration as workaround. Reviewed-by:
Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by:
-
Peter Oberparleiter authored
When a task waiting for completion of a Store Data operation is interrupted, an attempt is made to halt this operation. If this attempt fails due to a hardware or firmware problem, there is a chance that the SCLP facility might store data into buffers referenced by the original operation at a later time. Handle this situation by not releasing the referenced data buffers if the halt attempt fails. For current use cases, this might result in a leak of few pages of memory in case of a rare hardware/firmware malfunction. Reviewed-by:
-
Peter Oberparleiter authored
On systems that do not support Store Data events (such as when running as KVM guest) the following warning message appears during boot: sclp_sd: Store Data request failed (eq=2, di=3, response=0x40f0, flags=0x00, status=0, rc=-5) This warning does not add any useful information since the result is expected due to missing support for that event type. Suppress this message by checking the associated masks of supported events before issuing a Store Data event. Suggested-by:
-
- 28 Jun, 2024 5 commits
-
-
Jeff Johnson authored
With ARCH=s390, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/s390/char/raw3270.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/s390/char/con3270.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/s390/char/fs3270.o Add the missing invocations of the MODULE_DESCRIPTION() macro. Acked-by:
Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20240615-md-s390-drivers-s390-char-v1-1-d1cd23ff6476@quicinc.comSigned-off-by:
-
Jeff Johnson authored
With ARCH=s390, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/s390/block/dcssblk.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Acked-by:
-
Jeff Johnson authored
With ARCH=s390, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in arch/s390/mm/cmm.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Acked-by:
-
Jeff Johnson authored
With ARCH=s390, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in arch/s390/lib/test_kprobes_s390.o WARNING: modpost: missing MODULE_DESCRIPTION() in arch/s390/lib/test_unwind.o WARNING: modpost: missing MODULE_DESCRIPTION() in arch/s390/lib/test_modules.o Add the missing invocations of the MODULE_DESCRIPTION() macro. Acked-by:
-
Jeff Johnson authored
With ARCH=s390, make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in arch/s390/crypto/crc32-vx_s390.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Acked-by:
-
- 24 Jun, 2024 2 commits
-
-
Wei Yang authored
On s390, zero page's size relies on total ram pages. Since we plan to move the accounting into __free_pages_core(), totalram_pages may not represent the total usable pages on system at this point when defer_init is enabled. We can get the total usable pages from memblock directly. The size maybe not accurate due to the alignment, but enough for the calculation. Signed-off-by:
Wei Yang <richard.weiyang@gmail.com> CC: Mike Rapoport (IBM) <rppt@kernel.org> CC: David Hildenbrand <david@redhat.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/20240616013537.20338-1-richard.weiyang@gmail.comSigned-off-by:
-
Heiko Carstens authored
Make use of the popcnt instruction to provide optimized __arch_hweight*() implementations. The generated code is shorter and avoids rather expensive functions calls. Acked-by:
-
- 18 Jun, 2024 11 commits
-
-
Alexander Gordeev authored
Replace immediate values with SCLP_CMDW_UN|ASSIGN_STORAGE defines. Acked-by:
-
Sven Schnelle authored
With all users gone, remove S390_lowcore. Acked-by:
-
Sven Schnelle authored
Assign the output from get_lowcore() to a local variable, so the code is easier to read. Acked-by:
-
Sven Schnelle authored
Assign the output from get_lowcore() to a local variable, so the code is easier to read. Acked-by:
-
Sven Schnelle authored
Assign the output from get_lowcore() to a local variable, so the code is easier to read. Acked-by:
-
Sven Schnelle authored
Assign the output from get_lowcore() to a local variable, so the code is easier to read. Acked-by:
-
Sven Schnelle authored
Assign the output from get_lowcore() to a local variable, so the code is easier to read. Acked-by:
-
Sven Schnelle authored
Replace all S390_lowcore usages in arch/s390/boot by get_lowcore(). Acked-by:
-
Sven Schnelle authored
Replace all S390_lowcore usages in drivers/s390 by get_lowcore(). Acked-by:
-
Sven Schnelle authored
Replace all S390_lowcore usages in arch/s390/ by get_lowcore(). Acked-by:
-
Sven Schnelle authored
Add a get_lowcore() function which returns the address of lowcore (currently always NULL). This function will be used as a replacement of the S390_lowcore macro. Acked-by:
-
- 07 Jun, 2024 6 commits
-
-
Thomas Richter authored
The PMU for PAI NNPA counters enforces the following restriction: - No per-task context for PAI sampling event NNPA_ALL - No multiple system-wide PAI sampling event NNPA_ALL Both restrictions are removed. One or more per-task sampling events are supported. Also one or more system-wide sampling events are supported. Acked-by:
Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by:
Thomas Richter <tmricht@linux.ibm.com> Signed-off-by:
-
Thomas Richter authored
The PMU for PAI NNPA counters enforces the following restriction: - No per-task context for PAI NNPA counters. This restriction is removed. One or more per-task/system-wide counting events can now be active at the same time while one system wide sampling event is active. Acked-by:
-
Thomas Richter authored
The PMU for PAI NNPA counters enforces the following restriction: - No system wide counting while system wide sampling is active. This restriction is removed. One or more system wide counting events can now be active at the same time while at most one system wide sampling event is active. Acked-by:
-
Thomas Richter authored
The PMU for PAI crypto counters enforces the following restrictions: - No per-task context for PAI crypto sampling event CRYPTO_ALL - No multiple system-wide PAI crypto sampling event CRYPTO_ALL Both restrictions are removed. One or more per-task sampling events are supported. Also one or more system-wide sampling events are supported. Example for per-task context of sampling event CRYPTO_ALL: # perf record -e pai_crypto/CRYPTO_ALL/ -- true Example for system-wide context of sampling event CRYPTO_ALL: # perf record -e pai_crypto/CRYPTO_ALL/ -a -- sleep 4 Acked-by: -
Thomas Richter authored
The PMU for PAI crypto counters enforces the following restriction: - No per-task context for PAI crypto counters events. This restriction is removed. One or more per-task/system-wide counting events can now be active at the same time while at most one system wide sampling event is active. Example for per-task context of a PAI crypto counter event: # perf stat -e pai_crypto/KM_AES_128/ -- true Acked-by: -
Thomas Richter authored
The PMU for PAI crypto counters enforces the following restriction: - No system wide counting while system wide sampling is active. This restriction is removed. One or more system wide counting events can now be active at the same time while at most one system wide sampling event is active. Acked-by:
-
- 05 Jun, 2024 7 commits
-
-
David Hildenbrand authored
Let's make it clearer that we are always working on folio flags and never page flags of tail pages by converting remaining PG_arch_1 users that modify page->flags to modify folio->flags instead. No functional change intended, because we would always have worked with the head page (where page->flags corresponds to folio->flags) and never with tail pages. Reviewed-by:
-
David Hildenbrand authored
Let's also implement HAVE_ARCH_MAKE_FOLIO_ACCESSIBLE, so we can convert arch_make_page_accessible() to be a simple wrapper around arch_make_folio_accessible(). Unfortunately, we cannot do that in the header. There are only two arch_make_page_accessible() calls remaining in gup.c. We can now drop HAVE_ARCH_MAKE_PAGE_ACCESSIBLE completely form core-MM. We'll handle that separately, once the s390x part landed. Suggested-by:
Matthew Wilcox <willy@infradead.org> Reviewed-by:
-
David Hildenbrand authored
Let's do the same as we did for uv_destroy_(folio|pte)() and have the following variants: (1) uv_convert_from_secure(): "low level" helper that operates on paddr and does not mess with folios. (2) uv_convert_from_secure_folio(): Consumes a folio to which we hold a reference. (3) uv_convert_from_secure_pte(): Consumes a PTE that holds a reference through the mapping. Unfortunately we need uv_convert_from_secure_pte(), because pfn_folio() and friends are not available in pgtable.h. Reviewed-by:
-
David Hildenbrand authored
Let's have the following variants for destroying pages: (1) uv_destroy(): Like uv_pin_shared() and uv_convert_from_secure(), "low level" helper that operates on paddr and doesn't mess with folios. (2) uv_destroy_folio(): Consumes a folio to which we hold a reference. (3) uv_destroy_pte(): Consumes a PTE that holds a reference through the mapping. Unfortunately we need uv_destroy_pte(), because pfn_folio() and friends are not available in pgtable.h. Reviewed-by:
-
David Hildenbrand authored
It's not used outside of uv.c, so let's make it a static function. Reviewed-by:
-
David Hildenbrand authored
We removed the usage of PG_arch_1 for page tables in commit a51324c4 ("s390/cmma: rework no-dat handling"). Let's update the comment in UV to reflect that. Reviewed-by:
-
David Hildenbrand authored
Now that make_folio_secure() may only set PG_arch_1 for small folios, let's convert relevant remaining UV code to only work on (small) folios and simply reject large folios early. This way, we'll never end up touching PG_arch_1 on tail pages of a large folio in UV code. The folio_get()/folio_put() for functions that are documented to already hold a folio reference look weird; likely they are required to make concurrent gmap_make_secure() back off because the caller might only hold an implicit reference due to the page mapping. So leave that alone for now. Reviewed-by:
-
