ap_dqap(9)

💅 ap_dqap — no wait bestie it's ap_dqap(9)

okay so this is a page from the Kernel API Manual and it's all about pulling a message off an adjunct processor queue. s390 kernel vibes only, iykyk 🦋

---

✨ NAME ✨

ap_dqap — Receive message from adjunct processor queue. literally what it says on the tin, no cap 💖

---

✨ SYNOPSIS ✨

struct ap_queue_status ap_dqap (ap_qid_t qid , unsigned long *psmid ,
void *msg , size_t msglen , size_t *length , size_t *reslength ,
unsigned long *resgr0 );

---

✨ ARGUMENTS ✨

• qid — The AP queue number. this is your queue's whole identity, be nice to it 👑
• psmid — Pointer to program supplied message identifier.
• msg — Pointer to message buffer. where the message actually lands 🎀
• msglen — Message buffer size.
• length — Pointer to length of actually written bytes.
• reslength — Residual length on return.
• resgr0 — input: gr0 value (only used if != 0), output: residual gr0 content. she's giving dual-purpose main character energy fr fr 💅

---

✨ DESCRIPTION ✨

Returns AP queue status structure. that's the whole point, we're here for the struct ap_queue_status 💜

okay so condition code 1 on DQAP means the receive has taken place but only partially. the response is incomplete, hence the DQAP is repeated. 🌀

Condition code 2 on DQAP also means the receive is incomplete, this time because a segment boundary was reached. Again, the DQAP is repeated. same energy, different reason, slay ✨

Note that gpr2 is used by the DQAP instruction to keep track of any 'residual' length, in case the instruction gets interrupted. Hence it gets zeroed before the instruction. lowkey important, don't skip this part 🙈

If the message does not fit into the buffer, this function will return with a truncated message and the reply in the firmware queue is not removed.

This is indicated to the caller with an ap_queue_status response_code value of all bits on (0xFF) and (if the reslength ptr is given) the remaining length is stored in *reslength and (if the resgr0 ptr is given) the updated gr0 value for further processing of this msg entry is stored in *resgr0.

The caller needs to detect this situation and should invoke ap_dqap with a valid resgr0 ptr and a value in there != 0 to indicate that *resgr0 is to be used instead of qid to further process this entry. like, you gotta notice it yourself, the function isn't gonna text you back about it 😭

---

✨ SEE ALSO ✨

• Kernel file ./arch/s390/include/asm/ap.h struct ap_queue_status(9)
• ap_instructions_available(9)
• ap_tapq(9)
• ap_test_queue(9)
• struct ap_config_info(9)
• ap_qci(9)
• ap_aqic(9)
• ap_qact(9)
• ap_nqap(9)

---

okay that's the whole page bestie 💖 this cutie lives in ./arch/s390/include/asm, dated October 2026, and goes by ap_dqap(9). go forth and receive your messages responsibly 🫶✨🌸