|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [PATCH] gnttab: maptrack handle shortage is not IOMMU related
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@xxxxxxxx>
---
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__ */
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |