get_update_locks_for_kvm(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… get_update_locks_for_kvm β€” from the Kernel API Manual, bestie

okay so this one's a locking page from the kernel API manual, and honestly? it's giving "VIP queue at the club" energy. because that's literally what it is β€” grabbing a whole stack of locks in exactly the right order or everything falls apart. no pressure 🫢


✨ NAME ✨

get_update_locks_for_kvm β€” grabs every lock you need to dynamically update a KVM guest's APCB, and grabs them in the correct order, because order is everything here πŸ”₯


🌸 SYNOPSIS 🌸

void get_update_locks_for_kvm (struct kvm *kvm );

πŸŽ€ ARGUMENTS πŸŽ€

  • kvm β€” a pointer to a struct kvm object that holds the KVM guest's APCB. that's the whole vibe. πŸ’–

πŸ¦‹ DESCRIPTION πŸ¦‹

so the proper locking order is this, and you cannot freestyle it β€” it's a numbered list for a reason, bestie:

  1. matrix_dev->guests_lock: needed so you can use the KVM pointer to update a KVM guest's APCB.
  2. kvm->lock: needed to update a guest's APCB.
  3. kvm->arch.crypto.pqap_hook_rwsem: needed to update pqap_hook, and it serializes against PQAP intercepts.
  4. matrix_dev->mdevs_lock: needed to access data stored in a matrix_mdev.

like… lock one, lock two, lock three, lock four. in that order. periodt. πŸ’…


πŸ‘‘ NOTE πŸ‘‘

if kvm is NULL, the KVM lock and pqap_hook_rwsem will not be taken. so like, they just don't show up to the party. noted. 🫑

🌈 SEE ALSO 🌈

kernel file ./drivers/s390/crypto/vfio_ap_ops.c β€” that's the source, go read it iykyk πŸ“–

and the whole friend group πŸ’œ:


and that's the whole page, bestie πŸ’– this lil icon lives in ./drivers/s390/crypto, dated October 2026, and it ate, no cap. mwah πŸŽ€βœ¨πŸ‘‘

πŸ“¦ where this page comes from