On 11/6/19 3:19 PM, Jan Beulich wrote: > In order for individual IOMMU drivers (and from an abstract pov also > architectures) to be able to adjust their data structures ahead of time > when they might cover only a sub-range of all possible GFNs, introduce > a notification call used by various code paths potentially installing a > fresh mapping of a never used GFN (for a particular domain).
So trying to reverse engineer what's going on here, you mean to say something like this: --- Individual IOMMU drivers contain adjuct data structures for gfn ranges contained in the main p2m. For efficiency, these adjuct data structures often cover only a subset of the gfn range. Installing a fresh mapping of a never-used gfn may require these ranges to be expanded. Doing this when the p2m entry is first updated may be problematic because <reasons>. To fix this, implement notify_gfn(), to be called when Xen first becomes aware that a potentially new gfn may be about to be used. This will notify the IOMMU driver about the new gfn, allowing it to expand the data structures. It may return -ERESTART (?) for long-running operations, in which case the operation should be restarted or a different error if the expansion of the data structure is not possible. In the latter case, the entire operation should fail. --- Is that about right? Note I've had to make a lot of guesses here about the functionality and intent. > Note that in gnttab_transfer() the notification and lock re-acquire > handling is best effort only (the guest may not be able to make use of > the new page in case of failure, but that's in line with the lack of a > return value check of guest_physmap_add_page() itself). Is there a reason we can't just return an error to the caller? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
