release_upda...ocks_for_kvm(9)

📦 version 7.3.1, in nixpkgs unstable

okay bestie, welcome to the Kernel API Manual page for release_update_locks_for_kvm(9) — yes that's the real name, the header truncates it as release_upda...ocks_for_kvm(9) but we don't do that to ourselves 💅

🎀 NAME

release_update_locks_for_kvm — releases the locks you used to dynamically update a KVM guest's APCB, and it does it in the proper order. no cap, the order is the whole point 🔥

✨ SYNOPSIS

void release_update_locks_for_kvm (struct kvm *kvm );

🦋 ARGUMENTS

  • kvm — a pointer to a struct kvm object that contains the KVM guest's APCB. that's it, that's the whole argument, she's simple like that 🫶

💖 DESCRIPTION

okay so when you're dynamically updating a KVM guest's APCB, you grabbed a bunch of locks, right? this function is the "and now we let go" moment. but bestie, you can't just release them in any order — there's a proper unlocking order and it is literally this, in this exact sequence:

  1. matrix_dev->mdevs_lock
  2. kvm->arch.crypto.pqap_hook_rwsem
  3. kvm->lock
  4. matrix_dev->guests_lock

lowkey iconic how tidy that is. follow the order, don't freestyle 💀

⭐ NOTE

if kvm is NULL, then the KVM lock and pqap_hook_rwsem will not be released. so like, know what you're passing, bestie 🙈

💜 SEE ALSO

the source lives in this kernel file:

./drivers/s390/crypto/vfio_ap_ops.c

and here's the full squad — every single one of these, no skips 🌈:

and that's the page!! 🎀✨ this lil beauty ships from ./drivers/s390/crypto, dated October 2026, under the Kernel API Manual umbrella. go forth and release your locks in order, queen 👑💅🍓

📦 where this page comes from