Some hypercalls, memory-op in particular, can return values requiring
more than 31 bits to represent. Hence the underlying layers need to make
sure they won't truncate such values.
Signed-off-by: Jan Beulich
Acked-by: Ian Jackson
---
v2: Move dropping of xencall6 from the version script to a separate
patch.
---
I wasn't sure whether equivalents for the other xencall() should also
be introduced, and hence I went for the minimal solution first. Otoh
there's also xencall0() without any users ...
--- a/tools/include/xencall.h
+++ b/tools/include/xencall.h
@@ -113,6 +113,10 @@ int xencall5(xencall_handle *xcall, unsi
uint64_t arg1, uint64_t arg2, uint64_t arg3,
uint64_t arg4, uint64_t arg5);
+/* Variant(s) of the above, as needed, returning "long" instead of "int". */
+long xencall2L(xencall_handle *xcall, unsigned int op,
+ uint64_t arg1, uint64_t arg2);
+
/*
* Allocate and free memory which is suitable for use as a pointer
* argument to a hypercall.
--- a/tools/libs/call/core.c
+++ b/tools/libs/call/core.c
@@ -127,6 +127,17 @@ int xencall2(xencall_handle *xcall, unsi
return osdep_hypercall(xcall, &call);
}
+long xencall2L(xencall_handle *xcall, unsigned int op,
+ uint64_t arg1, uint64_t arg2)
+{
+privcmd_hypercall_t call = {
+.op = op,
+.arg = { arg1, arg2 },
+};
+
+return osdep_hypercall(xcall, &call);
+}
+
int xencall3(xencall_handle *xcall, unsigned int op,
uint64_t arg1, uint64_t arg2, uint64_t arg3)
{
--- a/tools/libs/call/libxencall.map
+++ b/tools/libs/call/libxencall.map
@@ -27,3 +27,8 @@ VERS_1.2 {
global:
xencall_fd;
} VERS_1.1;
+
+VERS_1.3 {
+ global:
+ xencall2L;
+} VERS_1.2;
