xe_sriov_vfio_flr_prepare(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… xe_sriov_vfio_flr_prepare(9) β€” like, the whole kernel API manual vibe πŸŽ€

okay bestie so you're reading the Kernel API Manual page for xe_sriov_vfio_flr_prepare(9) and honestly? it's a little baddie of a function. let's get into it ✨


🌸 NAME 🌸

xe_sriov_vfio_flr_prepare β€” notify the PF that VF FLR prepare has started. that's it, that's the whole job πŸ’…


✨ SYNOPSIS ✨

int xe_sriov_vfio_flr_prepare (struct xe_device *xe , unsigned int vfid
);

look at her go 🫢 one call, two args, int coming back at you.


πŸ¦‹ ARGUMENTS πŸ¦‹

  • xe β€” the PF xe_device, and you get it by calling xe_sriov_vfio_get_pf. that's the only way in, no cap πŸ”₯
  • vfid β€” the VF identifier. and bestie, listen: it can't be 0. zero is not invited to this party πŸ™ˆ

πŸ’– DESCRIPTION πŸ’–

so what does she do? this function marks the VF FLR as pending before the PF receives the GuC FLR event. that's the whole tea β˜• the timing is literally the point β€” pending gets set first, GuC event comes after. iykyk πŸ’€


🌈 RETURN 🌈

  • 0 β†’ slay, it worked, success πŸ‘‘
  • a negative error code β†’ not slay, it failed 😭

πŸŽ€ SEE ALSO πŸŽ€

the whole friend group, plus the kernel file they live in:


πŸ’œ friendly rememinder: vfid can't be 0. i said what i said.

mwah πŸ’‹ that's the page!! sourced from ./include/drm/intel, dated October 2026, and it's giving main character energy all the way through. go read some more manpages bestie, love u, bye πŸ§šβ€β™€οΈπŸŒΈ

πŸ“¦ where this page comes from