Re: [PATCH 7/7] x86: add iommu_ops to map and unmap pages, and also to flush the IOTLB

[Paul Durrant <Paul.Durrant@citrix.com>]

> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@intel.com]
> Sent: 13 February 2018 06:56
> To: Paul Durrant <Paul.Durrant@citrix.com>; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini <sstabellini@kernel.org>; Wei Liu
> <wei.liu2@citrix.com>; George Dunlap <George.Dunlap@citrix.com>;
> Andrew Cooper <Andrew.Cooper3@citrix.com>; Ian Jackson
> <Ian.Jackson@citrix.com>; Tim (Xen.org) <tim@xen.org>; Jan Beulich
> <jbeulich@suse.com>
> 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?

Kevin,

The main changes are:

- there is no op to query mapping capability... instead the hypercall will fail with -EACCES
- there is no longer an option to avoid reference counting map and unmap operations
- 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 [1]
- there is no illusion that pages other 4k are supported at the moment
- the flush operation is now explicit

[1] 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
> requirement...
> 

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.

Cheers,

  Paul

> Thanks
> kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel