assign_adapter_store(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– assign_adapter_store(9) πŸ’–

okay so real talk, this is from the Kernel API Manual and it's the page for assign_adapter_store β€” she's the one who parses the APID out of @buf and sets the matching bit in the mediated matrix device's APM. iconic behavior tbh πŸŽ€


✨ SYNOPSIS ✨

ssize_t assign_adapter_store (struct device *dev , struct
device_attribute *attr , const char *buf , size_t count );

🫢 ARGUMENTS 🫢

  • dev β€” the matrix device, bestie. main character.
  • attr β€” the mediated matrix device's assign_adapter attribute. she's the vibe.
  • buf β€” a buffer holding the AP adapter number (APID) that's getting assigned πŸ’…
  • count β€” the number of bytes in buf (yes, literally just the byte count, ngl)

πŸ”₯ RETURN πŸ”₯

if the APID is valid you get the number of bytes processed β€” slay ✨. otherwise? one of the following errors gets thrown at you:


🌸 DESCRIPTION 🌸

here's your error lineup, numbered and everything, no cap:

  1. -EINVAL β€” the APID is not a valid number πŸ™ˆ
  2. -ENODEV β€” the APID exceeds the maximum value configured for the system πŸ’€
  3. -EADDRNOTAVAIL β€” an APQN derived from the cross product of the APID being assigned and the APQIs previously assigned is not bound to the vfio_ap device driver; or, if no APQIs have yet been assigned, the APID is not contained in an APQN bound to the vfio_ap device driver 😭
  4. -EADDRINUSE β€” an APQN derived from the cross product of the APID being assigned and the APQIs previously assigned is being used by another mediated matrix device 🫠
  5. -EAGAIN β€” a lock required to validate the mdev's AP configuration could not be obtained πŸ’€
lowkey listen: those cross-product APQN checks are doing a LOT of heavy lifting, so don't be surprised when -EADDRNOTAVAIL or -EADDRINUSE shows up. read the number, read the reason, periodt.

πŸ¦‹ SEE ALSO πŸ¦‹

kernel file: ./drivers/s390/crypto/vfio_ap_ops.c πŸ‘‘

and the whole friend group:

get_update_locks_for_kvm(9), release_update_locks_for_kvm(9), get_update_locks_for_mdev(9), release_update_locks_for_mdev(9), get_update_locks_by_apqn(9), get_update_locks_for_queue(9), vfio_ap_mdev_get_queue(9), vfio_ap_wait_for_irqclear(9), vfio_ap_free_aqic_resources(9), vfio_ap_irq_disable(9), vfio_ap_validate_nib(9), ensure_nib_shared(9), vfio_ap_irq_enable(9), vfio_ap_le_guid_to_be_uuid(9), handle_pqap(9), vfio_ap_mdev_verify_no_sharing(9), vfio_ap_mdev_validate_masks(9), vfio_ap_mdev_unlink_adapter(9), unassign_adapter_store(9), assign_domain_store(9), unassign_domain_store(9), assign_control_domain_store(9), unassign_control_domain_store(9), vfio_ap_mdev_set_kvm(9), vfio_ap_mdev_unset_kvm(9), vfio_ap_mdev_resource_in_use(9), vfio_ap_mdev_hot_unplug_cfg(9), vfio_ap_mdev_cfg_remove(9), vfio_ap_mdev_on_cfg_remove(9), vfio_ap_filter_apid_by_qtype(9), vfio_ap_mdev_cfg_add(9), vfio_ap_mdev_on_cfg_add(9), vfio_ap_on_cfg_changed(9)


okay that's the whole page, go read it and get your APID assigned bestie πŸŒˆπŸ’œ

sign-off time: this cutie lives in ./drivers/s390/crypto and the page is dated October 2026 β€” mwah, assign_adapter_store(9) out πŸ’…βœ¨πŸŽ€

πŸ“¦ where this page comes from