Hi Jason, On Wed, 19 Aug 2026 09:46:52 -0300 Jason Gunthorpe <[email protected]> wrote:
> On Tue, Aug 18, 2026 at 05:13:29PM -0700, Mukesh R wrote: > > On 8/18/26 16:48, Jason Gunthorpe wrote: > > > On Tue, Aug 18, 2026 at 04:39:32PM -0700, Mukesh R wrote: > > > > > > > Thanks for the review. I know there is another set of patches > > > > for pvIOMMU ongoing (both came from the same source) and you > > > > are probably repeating things, and I appreciate your patience. > > > > I'll also try to look for your comments in that patch series > > > > going forward. > > > > > > Those patches look pretty good so you should try to copy their > > > stuff :) > > > > > > They ended up never calling detach, I hope you can do that too. > > > Just > > > > Unfortunately, my case is a bit different due to the "direct attach" > > feature for guest VMs. When a device moves from say a paging domain > > to be directly attached to a VM, today, it must first be detached. > > But since that just moves to identity, I am discussing with hyp > > team if detach is really required, and if we can get rid of it via > > just attaching to identity/blocked first before doing the direct > > attach. Hopefully, it can be done even if changes are needed in the > > hypervisor. > > You definately cannot have it blip to identity, that is security > unacceptable for VFIO. > > Once it is attached to VFIO it must only be blocked or under a > translation controlled by VFIO. Never something else. Based on this requirement, I don't see there is a difference between this root driver and the guest driver in terms of VFIO DMA ownership transition in the layer above the immediate hypercall site. i.e. old domain -> blocking domain -> new target domain Regardless of source or target domain type (e.g. direct attach as the target domain), the blocking domain must be attached. If the hypervisor detach operation internally implies transition through identity, then it needs to be hidden behind the blocking-domain attach transaction.
