> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: 11 July 2018 12:46
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Julien
> Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ; Tim
> (Xen.org) ; Wei Liu
> Subject: Re: [PATCH v2 12/13] x86: add iommu_ops to modify and flush
> IOMMU mappings
>
> On 07/07/2018 12:05 PM, Paul Durrant wrote:
> > This patch adds iommu_ops to add (map) or remove (unmap) frames in the
> > domain's IOMMU mappings, and an iommu_op to synchronize (flush)
> those
> > manipulations with the hardware.
> >
> > Mappings added by the map operation are tracked and only those
> mappings
> > may be removed by a subsequent unmap operation. Frames are specified
> by the
> > owning domain and GFN. It is, of course, permissable for a domain to map
> > its own frames using DOMID_SELF.
> >
> > NOTE: The owning domain and GFN must also be specified in the unmap
> > operation, as well as the BFN, so that they can be cross-checked
> > with the existent mapping.
> >
> > Signed-off-by: Paul Durrant
>
> The code on the whole looks correct, but I don't see any reference
> counting. The call to get_paged_gfn() in iommuop_unmap() kind of
> underlines the issue -- what's to stop the following sequence of events?
>
> * iommuop_map() page A
> * share(A)
> * DMA write into A #
>
I don't follow. In iommuop_map() we do a get_paged_gfn() and that reference is
retained. In iommuop_unmap() there is another call to get_paged_gfn() but that
is there to check that the specified gfn matches the mfn that's looked up in
the IOMMU. Only if they match is the original page ref dropped.
Paul
> -George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
