> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.t...@intel.com]
> Sent: 13 February 2018 06:56
> To: Paul Durrant <paul.durr...@citrix.com>; firstname.lastname@example.org
> Cc: Stefano Stabellini <sstabell...@kernel.org>; Wei Liu
> <wei.l...@citrix.com>; George Dunlap <george.dun...@citrix.com>;
> Andrew Cooper <andrew.coop...@citrix.com>; Ian Jackson
> <ian.jack...@citrix.com>; Tim (Xen.org) <t...@xen.org>; Jan Beulich
> Subject: RE: [Xen-devel] [PATCH 7/7] x86: add iommu_ops to map and
> unmap pages, and also to flush the IOTLB
> > From: Paul Durrant
> > Sent: Monday, February 12, 2018 6:47 PM
> > This patch adds iommu_ops to allow a domain with control_iommu
> > privilege
> > to map and unmap pages from any guest over which it has mapping
> > privilege
> > in the IOMMU.
> > These operations implicitly disable IOTLB flushing so that the caller can
> > batch operations and then explicitly flush the IOTLB using the iommu_op
> > also added by this patch.
> given that last discussion is 2yrs ago and you said actual implementation
> already biased from original spec, it'd be difficult to judge whether current
> change is sufficient or just 1st step. Could you summarize what have
> been changed from last spec, and also any further tasks in your TODO list?
The main changes are:
- there is no op to query mapping capability... instead the hypercall will fail
- there is no longer an option to avoid reference counting map and unmap
- there are no longer separate ops for mapping local and remote pages
(DOMID_SELF should be passed to the map op for local pages), and ops always
deal with GFNs not MFNs
- also I have dropped the idea of a global m2b map, so...
- it is now going to be the responsibility of the code running in the mapping
domain to track what it has mapped 
- there is no illusion that pages other 4k are supported at the moment
- the flush operation is now explicit
 this would be an issue if the interface becomes usable for anything other
than dom0 as we'd also need something in Xen to release the page refs if the
domain was forcibly destroyed, but I think the m2b was the wrong solution since
it necessitates a full scan of *host* RAM on any domain destruction
The main item on my TODO list is to implement a new IOREQ to allow invalidation
of specific guest pages. Think of the current 'invalidate map cache' as a
global flush... I need a specific flush so that a decrease_reservation
hypercall issued by a guest can instead tell emulators exactly which pages are
being removed from guest. It is then the emulators' responsibilities to unmap
those pages if they had them mapped (either through MMU or IOMMU) which then
drop page refs and actually allow the pages to be recycled.
I will, of course, need to come up with more Linux code to test all this, which
will eventually lead to kernel and user APIs to allow emulators running in dom0
to IOMMU map guest pages.
> at least just map/unmap operations definitely not meet XenGT
What aspect of the hypercall interface does not meet XenGT's requirements? It
would be good to know now then I can make any necessary adjustments in v2.
Xen-devel mailing list