On 3/31/2023 7:24 AM, Alex Elder wrote:
On 3/3/23 7:06 PM, Elliot Berman wrote:
Add architecture-independent standard error codes, types, and macros for
Gunyah hypercalls.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
Signed-off-by: Elliot Berman <quic_eberman@xxxxxxxxxxx>
See a few comments below. -Alex
---
include/linux/gunyah.h | 83 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 83 insertions(+)
create mode 100644 include/linux/gunyah.h
diff --git a/include/linux/gunyah.h b/include/linux/gunyah.h
new file mode 100644
index 000000000000..54b4be71caf7
--- /dev/null
+++ b/include/linux/gunyah.h
@@ -0,0 +1,83 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All
rights reserved.
+ */
+
+#ifndef _LINUX_GUNYAH_H
+#define _LINUX_GUNYAH_H
+
+#include <linux/errno.h>
+#include <linux/limits.h>
+
+/******************************************************************************/
+/* Common arch-independent definitions for Gunyah
hypercalls */
+#define GH_CAPID_INVAL U64_MAX
+#define GH_VMID_ROOT_VM 0xff
The above definition doesn't seem to be used anywhere, but seeing
it begs the question to me of what type it is expected to have.
If it were used, where would it be used in an 8 bit field?
VMIDs are u16, the root VM (Resource Manager) VMID is 0xff. I think this
definition snuck in from the downstream code and is indeed not being
needed/used anywhere. I'll remove it.
+
+enum gh_error {
+ GH_ERROR_OK = 0,
+ GH_ERROR_UNIMPLEMENTED = -1,
+ GH_ERROR_RETRY = -2,
There might be nothing fundamentally wrong with this, but I
dislike seeing negative values assigned to enums.
These error values are returned from the hypervisor, and it
looks like they'll likely truncated from a 64-bit unsigned
value. Are they *sent* from the hypervisor as 64-bit signed
values? Or 32-bit signed values? (In that case, the
I just wonder if you can use 0xffffffff or 0xffff for example
rather than -1, depending on the actual value that gets passed.
They are sent from the hypervisor as 64-bit signed values (it's filling
a register). I think truncating should be OK because Gunyah wants to
maintain capability with 32-bit architectures and we would not see an
error number that truly requires more than 32 bits to represent.
+
+ GH_ERROR_ARG_INVAL = 1,
+ GH_ERROR_ARG_SIZE = 2,
+ GH_ERROR_ARG_ALIGN = 3,
+
+ GH_ERROR_NOMEM = 10,
+
+ GH_ERROR_ADDR_OVFL = 20,
+ GH_ERROR_ADDR_UNFL = 21,
+ GH_ERROR_ADDR_INVAL = 22,
+
+ GH_ERROR_DENIED = 30,
+ GH_ERROR_BUSY = 31,
+ GH_ERROR_IDLE = 32,
+
+ GH_ERROR_IRQ_BOUND = 40,
+ GH_ERROR_IRQ_UNBOUND = 41,
+
+ GH_ERROR_CSPACE_CAP_NULL = 50,
+ GH_ERROR_CSPACE_CAP_REVOKED = 51,
+ GH_ERROR_CSPACE_WRONG_OBJ_TYPE = 52,
+ GH_ERROR_CSPACE_INSUF_RIGHTS = 53,
+ GH_ERROR_CSPACE_FULL = 54,
+
+ GH_ERROR_MSGQUEUE_EMPTY = 60,
+ GH_ERROR_MSGQUEUE_FULL = 61,
+};
+
+/**
+ * gh_remap_error() - Remap Gunyah hypervisor errors into a Linux
error code
+ * @gh_error: Gunyah hypercall return value
+ */
+static inline int gh_remap_error(enum gh_error gh_error)
Since you're remapping a gh_error, I would have named this
gh_error_remap().
Done.
+{
+ switch (gh_error) {
+ case GH_ERROR_OK:
+ return 0;
+ case GH_ERROR_NOMEM:
+ return -ENOMEM;
+ case GH_ERROR_DENIED:
+ case GH_ERROR_CSPACE_CAP_NULL:
+ case GH_ERROR_CSPACE_CAP_REVOKED:
+ case GH_ERROR_CSPACE_WRONG_OBJ_TYPE:
+ case GH_ERROR_CSPACE_INSUF_RIGHTS:
+ case GH_ERROR_CSPACE_FULL:
+ return -EACCES;
+ case GH_ERROR_BUSY:
+ case GH_ERROR_IDLE:
+ return -EBUSY;
+ case GH_ERROR_IRQ_BOUND:
+ case GH_ERROR_IRQ_UNBOUND:
+ case GH_ERROR_MSGQUEUE_FULL:
+ case GH_ERROR_MSGQUEUE_EMPTY:
+ return -EIO;
+ case GH_ERROR_UNIMPLEMENTED:
+ case GH_ERROR_RETRY:
+ return -EOPNOTSUPP;
+ default:
+ return -EINVAL;
+ }
+}
+
+#endif
