Both comment and message string associated with GNTST_no_device_space
suggest a connection to the IOMMU. A lack of maptrack handles has
nothing to do with that; it's unclear to me why commit 6213b696ba65
("Grant-table interface redone") introduced it this way. Introduce a
new error indicator.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Or should this be a more specific one, e.g. GNTST_no_mt_handle? If not,
I would intend to also use GNTST_no_space for -ENOMEM like situations.

--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1027,7 +1027,7 @@ map_grant_ref(
     {
         rcu_unlock_domain(rd);
         gdprintk(XENLOG_INFO, "Failed to obtain maptrack handle\n");
-        op->status = GNTST_no_device_space;
+        op->status = GNTST_no_space;
         return;
     }
 
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -652,6 +652,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_cache_flu
 #define GNTST_bad_copy_arg    (-10) /* copy arguments cross page boundary.   */
 #define GNTST_address_too_big (-11) /* transfer page address too large.      */
 #define GNTST_eagain          (-12) /* Operation not done; try again.        */
+#define GNTST_no_space        (-13) /* Out of space (handles etc).           */
 /* ` } */
 
 #define GNTTABOP_error_msgs {                   \
@@ -667,7 +668,8 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_cache_flu
     "bad page",                                 \
     "copy arguments cross page boundary",       \
     "page address size too large",              \
-    "operation not done; try again"             \
+    "operation not done; try again",            \
+    "out of space",                             \
 }
 
 #endif /* __XEN_PUBLIC_GRANT_TABLE_H__ */

Hi Jan,

On 30/08/2021 15:27, Jan Beulich wrote:
> Both comment and message string associated with GNTST_no_device_space
> suggest a connection to the IOMMU. A lack of maptrack handles has
> nothing to do with that; it's unclear to me why commit 6213b696ba65
> ("Grant-table interface redone") introduced it this way. Introduce a
> new error indicator.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Or should this be a more specific one, e.g. GNTST_no_mt_handle? If not,
> I would intend to also use GNTST_no_space for -ENOMEM like situations.

I guess the guest could use GNTSTS_no_mt_handle to reduce the number of 
persistent mappings (if there are any).

Although, I am not sure how involved it would be in OS like Linux.

Anyway, the new error status is better than the previous one. So I am 
happy with either solutions:

Acked-by: Julien Grall <jgrall@amazon.com>

Cheers,

-- 
Julien Grall