> -----Original Message----- > From: Paul Durrant <p...@xen.org> > Sent: 30 July 2020 15:29 > To: xen-devel@lists.xenproject.org > Cc: Durrant, Paul <pdurr...@amazon.co.uk>; Jan Beulich <jbeul...@suse.com>; > Andrew Cooper > <andrew.coop...@citrix.com>; Wei Liu <w...@xen.org>; Roger Pau Monné > <roger....@citrix.com>; George > Dunlap <george.dun...@citrix.com>; Ian Jackson <ian.jack...@eu.citrix.com>; > Julien Grall > <jul...@xen.org>; Stefano Stabellini <sstabell...@kernel.org>; Jun Nakajima > <jun.nakaj...@intel.com>; > Kevin Tian <kevin.t...@intel.com> > Subject: [EXTERNAL] [PATCH v2 08/10] remove remaining uses of > iommu_legacy_map/unmap > > CAUTION: This email originated from outside of the organization. Do not click > links or open > attachments unless you can confirm the sender and know the content is safe. > > > > From: Paul Durrant <pdurr...@amazon.com> > > The 'legacy' functions do implicit flushing so amend the callers to do the > appropriate flushing. > > Unfortunately, because of the structure of the P2M code, we cannot remove > the per-CPU 'iommu_dont_flush_iotlb' global and the optimization it > facilitates. It is now checked directly iommu_iotlb_flush(). Also, it is > now declared as bool (rather than bool_t) and setting/clearing it are no > longer pointlessly gated on is_iommu_enabled() returning true. (Arguably > it is also pointless to gate the call to iommu_iotlb_flush() on that > condition - since it is a no-op in that case - but the if clause allows > the scope of a stack variable to be restricted). > > NOTE: The code in memory_add() now fails if the number of pages passed to > a single call overflows an unsigned int. I don't believe this will > ever happen in practice. > > Signed-off-by: Paul Durrant <pdurr...@amazon.com>
I realise now that I completely forgot to address Jan's comments on grant table locking and flush batching, so there will be a v3 of at least this patch. Paul
