Hi Kevin, On 10/13/2023 1:10 AM, Tian, Kevin wrote: >> From: Chatre, Reinette <reinette.chatre@xxxxxxxxx> >> Sent: Saturday, October 7, 2023 12:41 AM >> >> A virtual device driver starts by initializing the backend >> using new vfio_pci_ims_init_intr_ctx(), cleanup using new >> vfio_pci_ims_release_intr_ctx(). Once initialized the virtual >> device driver can call vfio_pci_set_irqs_ioctl() to handle the >> VFIO_DEVICE_SET_IRQS ioctl() after it has validated the parameters >> to be appropriate for the particular device. > > I wonder whether the code sharing can go deeper from > vfio_pci_set_irqs_ioctl() all the way down to set_vector_signal() > with proper abstraction. There is a foundational difference in the MSI and IMS interrupt management that is handled by the separate set_vector_signal() implementations. For MSI interrupts the interrupts stay allocated but the individual interrupt context is always freed and re-allocated. For IMS the interrupts are always freed and re-allocated (to ensure that any new cookie is taken into account) while the individual interrupt context stays allocated (to not lose the cookie value associated with the individual interrupt). It may indeed be possible to accommodate this difference with further abstraction. I will study the code more to explore how this can be done. > Then handle emulated interrupt in the > common code instead of ims specific path. intel gvt also uses > emulated interrupt, which could be converted to use this library > too. Thank you for pointing me to intel gvt. > There is some subtle difference between pci/ims backends > regarding to how set_vector_signal() is coded in this series. But > it is not intuitive to me whether such a difference is conceptual > or simply from a coding preference. > > Would you mind doing an exercise whether that is achievable? I do not mind at all. Will do. Thank you very much for taking a look and sharing your guidance. Reinette
