On Fri, May 15, 2026 at 05:36:40PM +0000, Michael Kelley wrote: > From: Yu Zhang <[email protected]> Sent: Friday, May 15, 2026 9:54 > AM > > > > On Fri, May 15, 2026 at 02:51:38PM +0000, Michael Kelley wrote: > > > From: Yu Zhang <[email protected]> Sent: Friday, May 15, 2026 > > > 7:00 AM > > > > > > > > On Thu, May 14, 2026 at 06:13:24PM +0000, Michael Kelley wrote: > > > > > From: Yu Zhang <[email protected]> Sent: Monday, May 11, > > > > > 2026 9:24 AM > > [....] > > > > > > > > > > > Previous versions of this function did hv_iommu_detach_dev(). With > > > > > that call > > > > > removed from here, hv_iommu_detach_dev() is only called when > > > > > attaching a > > > > > domain to a device that already has a domain attached. Is it the case > > > > > that > > > > > Hyper-V doesn't require the detach as a cleanup step? > > > > > > > > > > > > > The IOMMU core attaches the device to release_domain (our blocking > > > > domain) > > > > before calling release_device(), so I believe the explicit detach in > > > > the RFC > > > > was redundant. I simply didn't realize that at the time. > > > > > > > > > > Got it. But after the IOMMU core attaches the device to the blocking > > > domain, there's the possibility that the vPCI device is rescinded by > > > Hyper-V and it goes away entirely. Or the device might be subjected > > > to an "unbind/bind" cycle in Linux. Does the detach need to be done > > > on the blocking domain in such cases? In this version of the patches, the > > > Hyper-V "attach" and "detach" hypercalls still end up unbalanced. That > > > seems a bit untidy at best, and I wonder if there are scenarios where > > > Hyper-V will complain about the lack of balance. > > > > > > > Thank you, Michael. May I ask what "the vPCI device is rescinded by > > Hyper-V and it goes away entirely" mean? > > > > See the documentation at Documentation/virt/hyperv/vpci.rst in a > kernel source code tree, and particularly the section entitled "PCI Device > Removal". Such removals can and do happen in running Azure guest > VMs. Start with that info and then I'll do my best to answer follow-up > questions you may have. > > The unbind/bind case is separate, but has some of the same effects in > that Linux should be removing all setup of the PCI device. There's actually > two unbind steps -- one to unbind the device-specific driver (e.g., the > Mellanox MLX5 driver or the NMVe driver) driver from the device, and > potentially a second to unbind the VMBus vPCI driver from the device. > These unbind/bind sequences can be done in the Linux guest without > the Hyper-V host rescinding the device.
Thanks for pointing me to the vpci.rst doc, Michael! IIUC, for the vPCI rescind case and the VMBus vPCI driver unbind case, both will trigger iommu_deinit_device(), in which IOMMU core attaches the device to our blocking domain. And hypervisor will handle such attaching to the blocking domain by essentially disable the DMA translation and IOPF for the device. Since the device is already in a safe state after that, I don't think an additional detach is necessary. For the device-specific driver unbind (e.g., unbind nvme then bind back, or bind to vfio-pci), that is transparent to the IOMMU layer. Also, while looking at Jason's comments on the detach/attach semantics, I'm now thinking that making the attach hypercall atomic (having the hypervisor handle the domain switch internally) might be a cleaner approach. That also eliminates the attach/detach imbalance issue entirely. I need to do some verification on the hypervisor side first, but will keep you posted. Thanks! B.R. Yu > > Michael >
