s390_sthyi(2)

✨ s390_sthyi(2) ✨

okay bestie, so this is the manual page for s390_sthyi from section 2 (that's the system calls girlies 💅) of the System Calls Manual. it's giving very niche, very s390, very main character. let's get into it 🫶

---

🌸 NAME 🌸

s390_sthyi — emulate STHYI instruction

like, that's literally the whole vibe. it pretends to do the thing. iconic.

---

🎀 LIBRARY 🎀

Standard C library (libc, -lc)

---

🦋 SYNOPSIS 🦋

#include <asm/sthyi.h>        /* Definition of STHYI_* constants */
#include <sys/syscall.h>      /* Definition of SYS_* constants */
#include <unistd.h>

int syscall(SYS_s390_sthyi, unsigned long function_code,
            void *resp_buffer, uint64_t *return_code,
            unsigned long flags);

not me having to say this: glibc provides no wrapper for s390_sthyi(), so you literally have to go through syscall(2). no cute little convenience function for us. we do it raw ✨

---

💖 DESCRIPTION 💖

The s390_sthyi() system call emulates the STHYI (Store Hypervisor Information) instruction. it hands you hardware resource info for the machine and all its virtualization levels — CPU type and capacity, the machine model, and a whole bunch of other metrics. very "here's your whole entire origin story" of it 🌈

The function_code argument says which function to actually perform. these are the code(s) we support, and there is exactly one:

• STHYI_FC_CP_IFL_CAP — return CP (Central Processor) and IFL (Integrated Facility for Linux) capacity information. periodt.

The resp_buffer argument is the address of a response buffer. when function_code is STHYI_FC_CP_IFL_CAP, that buffer must be one page (4K) in size — no smaller, bestie, don't try it 🙈. if the system call returns 0, the response buffer gets filled with CPU capacity info. otherwise? the response buffer's content is unchanged. nothing happens to it. it just sits there.

The return_code argument stores the return code of the STHYI instruction, and it's one of these two:

• 0 — Success. slay.
• 4 — Unsupported function code. 💀

want more deets on return_code, function_code, and resp_buffer? the reference is down in NOTES, go look 👀

The flags argument exists purely to allow for future extensions, and right now it must be set to 0. that's it. zero. don't be creative 🧚

---

👑 RETURN VALUE 👑

On success (that is: emulation succeeded), the return value of s390_sthyi() matches the condition code of the STHYI instructions, which is a value in the range [0..3].

• a return value of 0 means CPU capacity information is stored in *resp_buffer ✅
• a return value of 3 means "unsupported function code", and the content of *resp_buffer is unchanged 😭
• the return values 1 and 2 are reserved. don't touch, don't interpret, don't make it weird.

On error, -1 is returned, and errno is set to indicate the error.

---

🔥 ERRORS 🔥

• EFAULT — the value specified in resp_buffer or return_code is not a valid address. (bad pointer bestie, we've all been there)
• EINVAL — the value specified in flags is nonzero. we said 0. we meant 0.
• ENOMEM — allocating memory for handling the CPU capacity information failed. out of memory, of course 💀
• EOPNOTSUPP — the value specified in function_code is not valid. that function code is not it.

---

⭐ STANDARDS ⭐

Linux on s390.

---

🍓 HISTORY 🍓

Linux 4.15.

---

💜 NOTES 💜

• for the full details of the STHYI instruction, go read the documentation page 📖
• when you're going through the system call interface, your response buffer does not have to fulfill the alignment requirements described in the STHYI instruction definition. cute, right?
• the kernel caches the response (for up to one second, as of Linux 4.16). so subsequent system call invocations may return the cached response. yes, it's giving "I already answered that" energy 🙈

---

🌈 SEE ALSO 🌈

• syscall(2) — the one true doorway 🚪

---

vibe check complete. you now know everything this page knows, no cap. go forth and emulate that instruction 💅✨

---

this has been the s390_sthyi(2) page, brought to you by Linux man-pages 6.20, dated 2026-02-08, mwah 🫶