Re: [PATCH v3 4/5] iommu/hyperv: Add para-virtualized IOMMU support for Hyper-V guest
Yu Zhang <[email protected]>
| Newsgroups | org.kernel.vger.linux-pci,dev.linux.lists.iommu,org.kernel.vger.linux-arch,org.kernel.vger.linux-hyperv,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <aiioa6ospojivued3djhwadyfpit5temyvrgm3xxzhzt6aqbiv@hqz6q5bqnl6w> |
On Tue, Aug 18, 2026 at 12:01:13AM +0800, Yu Zhang wrote:
> On Mon, Aug 17, 2026 at 09:22:16AM -0300, Jason Gunthorpe wrote:
> > On Fri, Aug 14, 2026 at 05:37:48PM +0800, Yu Zhang wrote:
> > > > Why check it at all? Is there an issue with attaching the same thing
> > > > twice? Will it blip the DMA or something?
> > >
> > > Actually, I do not think there should be any issue with attaching twice.
> > > Hyper-V *should* be able to accept such attachment. But I do not want to
> > > make such assumption just for a redundant hypercall.
> > >
> > > Does this reasoning make sense, or would you prefer that I remove the
> > > check?
> >
> > I would probably drop it. Having blocking always set blocking to the
> > HW regardless of what the SW tracking state says feels more robust to
> > me.
> >
>
> Got it. Will drop the check and make sure each blocking request
> reasserts the blocking state in Hyper-V at HW level.
>
Sorry, Jason - I replied too quickly. :(
Latest confirmation from Hyper-V team about the existing behavior is
that, a repeated attach of the same device to the same domain returns
HV_STATUS_DEVICE_ALREADY_IN_DOMAIN. This is established behavior, and
other guest OS is already following such contract.
So we could
- either keep the duplicate check in hv_iommu_blocking_attach_dev();
- or add code in our common helper, hv_iommu_attach_dev(), to treat
HV_STATUS_DEVICE_ALREADY_IN_DOMAIN also as successful explicitly.
And since normal paging-domain attaches do not have this duplicate
case, I'd prefer the first choice, to keep current check in
hv_iommu_blocking_attach_dev().
@Jacob @Jason Is this choice acceptible for you?
B.R.
Yu
> B.R.
> Yu
>
> > Jason
> >
>