Message ID | 20240610125713.86750-1-fgriffo@amazon.co.uk (mailing list archive) |
---|---|
Headers | show |
Series | vfio/pci: add msi interrupt affinity support | expand |
Hello Fred. On Mon, Jun 10, 2024 at 12:57:06PM GMT, Fred Griffoul <fgriffo@amazon.co.uk> wrote: > The usual way to configure a device interrupt from userland is to write > the /proc/irq/<irq>/smp_affinity or smp_affinity_list files. When using > vfio to implement a device driver or a virtual machine monitor, this may > not be ideal: the process managing the vfio device interrupts may not be > granted root privilege, for security reasons. Thus it cannot directly > control the interrupt affinity and has to rely on an external command. External commands something privileged? (I'm curious of an example how this is setup.) > The affinity argument must be a subset of the process cpuset, otherwise > an error -EPERM is returned. I'm not sure you want to look at task's cpuset mask for this purposes. Consider setups without cpuset or a change of (cpuset) mask anytime during lifetime of the task... Michal
MIchal To be honest my initial idea was to store an affinity mask per vfio group, which can be done in the privileged process setting the vfio group/device owner, and later apply the mask to each interrupt of each device in the group. It would still require to fix the affinity of all the interrupts if the vfio group affinity is changed (or deliberately ignore this case). And it did not match exactly my use case where I need the process handling the interrupts to sometimes be able to change them but always within the cpuset. So I would still need the current patch, in addition to a new ioctl() to set the affinity mask of a vfio group. Br, Fred On Mon, Jun 10, 2024 at 5:31 PM Michal Koutný <mkoutny@suse.com> wrote: > > Hello Fred. > > On Mon, Jun 10, 2024 at 12:57:06PM GMT, Fred Griffoul <fgriffo@amazon.co.uk> wrote: > > The usual way to configure a device interrupt from userland is to write > > the /proc/irq/<irq>/smp_affinity or smp_affinity_list files. When using > > vfio to implement a device driver or a virtual machine monitor, this may > > not be ideal: the process managing the vfio device interrupts may not be > > granted root privilege, for security reasons. Thus it cannot directly > > control the interrupt affinity and has to rely on an external command. > > External commands something privileged? (I'm curious of an example how > this is setup.) > > > The affinity argument must be a subset of the process cpuset, otherwise > > an error -EPERM is returned. > > I'm not sure you want to look at task's cpuset mask for this purposes. > > Consider setups without cpuset or a change of (cpuset) mask anytime > during lifetime of the task... > > Michal
On Wed, Jun 12, 2024 at 03:45:48PM GMT, Frederic Griffoul <griffoul@gmail.com> wrote: > To be honest my initial idea was to store an affinity mask per vfio group, which > can be done in the privileged process setting the vfio group/device owner, and > later apply the mask to each interrupt of each device in the group. > > It would still require to fix the affinity of all the interrupts if > the vfio group affinity is > changed (or deliberately ignore this case). And it did not match > exactly my use case > where I need the process handling the interrupts to sometimes be able > to change them > but always within the cpuset. So I would still need the current patch, > in addition to > a new ioctl() to set the affinity mask of a vfio group. It's not clear to me what is the relation between the process A calling that ioctl() (and whose cpuset is used to check affinity for) and a process B that ends up handling the IRQ. At which place would process B be scheduled on IRQ's affinity CPUs? (I'm not familiar with VFIO.) Thanks, Michal