From: Alex Elder <elder@linaro.org> To: Elliot Berman <quic_eberman@quicinc.com>, Bjorn Andersson <quic_bjorande@quicinc.com>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Murali Nalajala <quic_mnalajal@quicinc.com> Cc: Trilok Soni <quic_tsoni@quicinc.com>, Srivatsa Vaddagiri <quic_svaddagi@quicinc.com>, Carl van Schaik <quic_cvanscha@quicinc.com>, Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>, Arnd Bergmann <arnd@arndb.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Jonathan Corbet <corbet@lwn.net>, Bagas Sanjaya <bagasdotme@gmail.com>, Jassi Brar <jassisinghbrar@gmail.com>, Sudeep Holla <sudeep.holla@arm.com>, Mark Rutland <mark.rutland@arm.com>, Lorenzo Pieralisi <lpieralisi@kernel.org>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org Subject: Re: [PATCH v8 05/28] virt: gunyah: Add hypercalls to identify Gunyah Date: Mon, 9 Jan 2023 15:34:25 -0600 [thread overview] Message-ID: <63bbc640-9b0c-95af-3d35-291da0323db3@linaro.org> (raw) In-Reply-To: <20221219225850.2397345-6-quic_eberman@quicinc.com> On 12/19/22 4:58 PM, Elliot Berman wrote: > Add hypercalls to identify when Linux is running a virtual machine under > Gunyah. > > There are two calls to help identify Gunyah: > > 1. gh_hypercall_get_uid() returns a UID when running under a Gunyah > hypervisor. > 2. gh_hypercall_hyp_identify() returns build information and a set of > feature flags that are supported by Gunyah. The first is a "service", while the second is a "hypercall". Can you explain the distinction? The sentence at the top refers to both as "hypercalls". > > Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > --- > MAINTAINERS | 2 + > arch/arm64/Kbuild | 1 + > arch/arm64/gunyah/Makefile | 1 + > arch/arm64/gunyah/gunyah_hypercall.c | 69 ++++++++++++++++++++++++++++ > drivers/virt/Kconfig | 1 + > drivers/virt/gunyah/Kconfig | 12 +++++ > include/linux/gunyah.h | 25 ++++++++++ > 7 files changed, 111 insertions(+) > create mode 100644 arch/arm64/gunyah/Makefile > create mode 100644 arch/arm64/gunyah/gunyah_hypercall.c > create mode 100644 drivers/virt/gunyah/Kconfig > > diff --git a/MAINTAINERS b/MAINTAINERS > index 74e76e0ab14d..36698df6b0e5 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -8941,6 +8941,8 @@ L: linux-arm-msm@vger.kernel.org > S: Supported > F: Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml > F: Documentation/virt/gunyah/ > +F: arch/arm64/gunyah/ > +F: drivers/virt/gunyah/ > F: include/linux/gunyah.h > > HABANALABS PCI DRIVER > diff --git a/arch/arm64/Kbuild b/arch/arm64/Kbuild > index 5bfbf7d79c99..e4847ba0e3c9 100644 > --- a/arch/arm64/Kbuild > +++ b/arch/arm64/Kbuild > @@ -3,6 +3,7 @@ obj-y += kernel/ mm/ net/ > obj-$(CONFIG_KVM) += kvm/ > obj-$(CONFIG_XEN) += xen/ > obj-$(subst m,y,$(CONFIG_HYPERV)) += hyperv/ > +obj-$(CONFIG_GUNYAH) += gunyah/ > obj-$(CONFIG_CRYPTO) += crypto/ > > # for cleaning > diff --git a/arch/arm64/gunyah/Makefile b/arch/arm64/gunyah/Makefile > new file mode 100644 > index 000000000000..9fbc720b6fb6 > --- /dev/null > +++ b/arch/arm64/gunyah/Makefile > @@ -0,0 +1 @@ > +obj-$(CONFIG_GUNYAH) += gunyah_hypercall.o > diff --git a/arch/arm64/gunyah/gunyah_hypercall.c b/arch/arm64/gunyah/gunyah_hypercall.c > new file mode 100644 > index 000000000000..0beb3123d650 > --- /dev/null > +++ b/arch/arm64/gunyah/gunyah_hypercall.c > @@ -0,0 +1,69 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved. > + */ > + > +#include <linux/arm-smccc.h> > +#include <linux/module.h> > +#include <linux/gunyah.h> > + > +#define GH_CALL_TYPE_PLATFORM_CALL 0 > +#define GH_CALL_TYPE_HYPERCALL 2 > +#define GH_CALL_TYPE_SERVICE 3 > +#define GH_CALL_TYPE_SHIFT 14 > +#define GH_CALL_FUNCTION_NUM_MASK 0x3fff A FN_ID is a 32-bit value. Are all 18 high-order bits considered part of the call type? It might be good to specify that explicitly by defining a mask for it. > + > +#define GH_FN_ID(type, num) ((type) << GH_CALL_TYPE_SHIFT | ((num) & GH_CALL_FUNCTION_NUM_MASK)) > + Is there any need for the endianness of these values to be specified? Does Gunyah operate with a well-defined endianness? Is there any chance a VM can run with an endianness different from Gunyah? I see that the arm_smcc_* structures are defined without endianness. (Sorry if these are dumb questions.) > +#define GH_SERVICE(fn) ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \ > + ARM_SMCCC_OWNER_VENDOR_HYP, \ > + GH_FN_ID(GH_CALL_TYPE_SERVICE, fn)) > + > +#define GH_HYPERCALL_CALL_UID GH_SERVICE(0x3f01) Perhaps 0x3f01 could be defined symbolically. However if this is the only place it's ever used, doing so doesn't add much value (meaning, just do it the way you did). > + > +#define GH_HYPERCALL(fn) ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_64, \ > + ARM_SMCCC_OWNER_VENDOR_HYP, \ > + GH_FN_ID(GH_CALL_TYPE_HYPERCALL, fn)) > + > +#define GH_HYPERCALL_HYP_IDENTIFY GH_HYPERCALL(0x0000) Will there be a growing set of well-known hypervisor call functions? Perhaps 0x0000 should be defined symbolically. (Or not if it's only used here.) > + > +/** > + * gh_hypercall_get_uid() - Returns a UID when running under a Gunyah hypervisor > + * @uid: An array of 4 u32's (u32 uid[4];) > + * > + * Caller should compare the resulting UID to a list of known Gunyah UIDs to > + * confirm that Linux is running as a guest of Gunyah. I presume that, if the returned UID isn't well-known, then no other Gunyah-related calls are meaningful. Is that correct? > + */ > +void gh_hypercall_get_uid(u32 uid[4]) > +{ > + struct arm_smccc_res res; > + > + arm_smccc_1_1_hvc(GH_HYPERCALL_CALL_UID, &res); > + > + uid[0] = res.a0; > + uid[1] = res.a1; > + uid[2] = res.a2; > + uid[3] = res.a3; I see in the definition of struct arm_smccc_res that the four fields are unsigned long values. That differs from the u32 array passed as argument. Are the resource IDs guaranteed to be four 32-bit values? I personally prefer being explicit about the upper 32-bits being discarded (though some don't agree with that convention). > +} > +EXPORT_SYMBOL_GPL(gh_hypercall_get_uid); > + > +/** > + * gh_hypercall_hyp_identify() - Returns build information and feature flags > + * supported by Gunyah. > + * @hyp_identity: filled by the hypercall with the API info and feature flags. > + */ > +void gh_hypercall_hyp_identify(struct gh_hypercall_hyp_identify_resp *hyp_identity) > +{ > + struct arm_smccc_res res; > + > + arm_smccc_1_1_hvc(GH_HYPERCALL_HYP_IDENTIFY, &res); > + > + hyp_identity->api_info = res.a0; > + hyp_identity->flags[0] = res.a1; > + hyp_identity->flags[1] = res.a2; > + hyp_identity->flags[2] = res.a3; > +} > +EXPORT_SYMBOL_GPL(gh_hypercall_hyp_identify); > + > +MODULE_LICENSE("GPL"); > +MODULE_DESCRIPTION("Gunyah Hypervisor Hypercalls"); > diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig > index 87ef258cec64..259dc2be6cad 100644 > --- a/drivers/virt/Kconfig > +++ b/drivers/virt/Kconfig > @@ -52,4 +52,5 @@ source "drivers/virt/coco/efi_secret/Kconfig" > > source "drivers/virt/coco/sev-guest/Kconfig" > > +source "drivers/virt/gunyah/Kconfig" > endif > diff --git a/drivers/virt/gunyah/Kconfig b/drivers/virt/gunyah/Kconfig > new file mode 100644 > index 000000000000..127156a678a6 > --- /dev/null > +++ b/drivers/virt/gunyah/Kconfig > @@ -0,0 +1,12 @@ > +# SPDX-License-Identifier: GPL-2.0-only > + > +config GUNYAH Maybe config QCOM_GUNYAH? Will this ever run on hardware other than Qualcomm's? > + tristate "Gunyah Virtualization drivers" > + depends on ARM64 > + help > + The Gunyah drivers are the helper interfaces that runs in a guest VM s/runs/run/ > + such as basic inter-VM IPC and signaling mechanisms, and higher level > + services such as memory/device sharing, IRQ sharing, and so on. > + > + Say Y/M here to enable the drivers needed to interact in a Gunyah > + virtual environment. > diff --git a/include/linux/gunyah.h b/include/linux/gunyah.h > index 824e20a11d27..2765d2b40198 100644 > --- a/include/linux/gunyah.h > +++ b/include/linux/gunyah.h > @@ -6,6 +6,7 @@ > #ifndef _GUNYAH_H > #define _GUNYAH_H > > +#include <linux/bitfield.h> > #include <linux/types.h> > #include <linux/errno.h> > > @@ -71,4 +72,28 @@ static inline int gh_remap_error(int gh_error) > } > } > > +#define GUNYAH_API_V1 1 > + > +#define GH_API_INFO_API_VERSION_MASK GENMASK_ULL(13, 0) > +#define GH_API_INFO_BIG_ENDIAN BIT_ULL(14) > +#define GH_API_INFO_IS_64BIT BIT_ULL(15) > +#define GH_API_INFO_VARIANT_MASK GENMASK_ULL(63, 56) > + How are the GH_IDENTIFY bits below used? Are they encoded in the three 64-bit flags fields in the response structure? Does that mean only the first of those three is (currently) used? > +#define GH_IDENTIFY_PARTITION_CSPACE BIT_ULL(0) > +#define GH_IDENTIFY_DOORBELL BIT_ULL(1) > +#define GH_IDENTIFY_MSGQUEUE BIT_ULL(2) > +#define GH_IDENTIFY_VIC BIT_ULL(3) > +#define GH_IDENTIFY_VPM BIT_ULL(4) > +#define GH_IDENTIFY_VCPU BIT_ULL(5) > +#define GH_IDENTIFY_MEMEXTENT BIT_ULL(6) > +#define GH_IDENTIFY_TRACE_CTRL BIT_ULL(7) > + > +struct gh_hypercall_hyp_identify_resp { > + u64 api_info; > + u64 flags[3]; > +}; Again I'll ask about endianness. This is a response coming *from* Gunyah. Is it guaranteed to use the same byte order convention as the running operating system (Linux) guest? -Alex > + > +void gh_hypercall_get_uid(u32 uid[4]); > +void gh_hypercall_hyp_identify(struct gh_hypercall_hyp_identify_resp *hyp_identity); > + > #endif
WARNING: multiple messages have this Message-ID (diff)
From: Alex Elder <elder@linaro.org> To: Elliot Berman <quic_eberman@quicinc.com>, Bjorn Andersson <quic_bjorande@quicinc.com>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Murali Nalajala <quic_mnalajal@quicinc.com> Cc: Trilok Soni <quic_tsoni@quicinc.com>, Srivatsa Vaddagiri <quic_svaddagi@quicinc.com>, Carl van Schaik <quic_cvanscha@quicinc.com>, Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>, Arnd Bergmann <arnd@arndb.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Jonathan Corbet <corbet@lwn.net>, Bagas Sanjaya <bagasdotme@gmail.com>, Jassi Brar <jassisinghbrar@gmail.com>, Sudeep Holla <sudeep.holla@arm.com>, Mark Rutland <mark.rutland@arm.com>, Lorenzo Pieralisi <lpieralisi@kernel.org>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org Subject: Re: [PATCH v8 05/28] virt: gunyah: Add hypercalls to identify Gunyah Date: Mon, 9 Jan 2023 15:34:25 -0600 [thread overview] Message-ID: <63bbc640-9b0c-95af-3d35-291da0323db3@linaro.org> (raw) In-Reply-To: <20221219225850.2397345-6-quic_eberman@quicinc.com> On 12/19/22 4:58 PM, Elliot Berman wrote: > Add hypercalls to identify when Linux is running a virtual machine under > Gunyah. > > There are two calls to help identify Gunyah: > > 1. gh_hypercall_get_uid() returns a UID when running under a Gunyah > hypervisor. > 2. gh_hypercall_hyp_identify() returns build information and a set of > feature flags that are supported by Gunyah. The first is a "service", while the second is a "hypercall". Can you explain the distinction? The sentence at the top refers to both as "hypercalls". > > Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > --- > MAINTAINERS | 2 + > arch/arm64/Kbuild | 1 + > arch/arm64/gunyah/Makefile | 1 + > arch/arm64/gunyah/gunyah_hypercall.c | 69 ++++++++++++++++++++++++++++ > drivers/virt/Kconfig | 1 + > drivers/virt/gunyah/Kconfig | 12 +++++ > include/linux/gunyah.h | 25 ++++++++++ > 7 files changed, 111 insertions(+) > create mode 100644 arch/arm64/gunyah/Makefile > create mode 100644 arch/arm64/gunyah/gunyah_hypercall.c > create mode 100644 drivers/virt/gunyah/Kconfig > > diff --git a/MAINTAINERS b/MAINTAINERS > index 74e76e0ab14d..36698df6b0e5 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -8941,6 +8941,8 @@ L: linux-arm-msm@vger.kernel.org > S: Supported > F: Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml > F: Documentation/virt/gunyah/ > +F: arch/arm64/gunyah/ > +F: drivers/virt/gunyah/ > F: include/linux/gunyah.h > > HABANALABS PCI DRIVER > diff --git a/arch/arm64/Kbuild b/arch/arm64/Kbuild > index 5bfbf7d79c99..e4847ba0e3c9 100644 > --- a/arch/arm64/Kbuild > +++ b/arch/arm64/Kbuild > @@ -3,6 +3,7 @@ obj-y += kernel/ mm/ net/ > obj-$(CONFIG_KVM) += kvm/ > obj-$(CONFIG_XEN) += xen/ > obj-$(subst m,y,$(CONFIG_HYPERV)) += hyperv/ > +obj-$(CONFIG_GUNYAH) += gunyah/ > obj-$(CONFIG_CRYPTO) += crypto/ > > # for cleaning > diff --git a/arch/arm64/gunyah/Makefile b/arch/arm64/gunyah/Makefile > new file mode 100644 > index 000000000000..9fbc720b6fb6 > --- /dev/null > +++ b/arch/arm64/gunyah/Makefile > @@ -0,0 +1 @@ > +obj-$(CONFIG_GUNYAH) += gunyah_hypercall.o > diff --git a/arch/arm64/gunyah/gunyah_hypercall.c b/arch/arm64/gunyah/gunyah_hypercall.c > new file mode 100644 > index 000000000000..0beb3123d650 > --- /dev/null > +++ b/arch/arm64/gunyah/gunyah_hypercall.c > @@ -0,0 +1,69 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved. > + */ > + > +#include <linux/arm-smccc.h> > +#include <linux/module.h> > +#include <linux/gunyah.h> > + > +#define GH_CALL_TYPE_PLATFORM_CALL 0 > +#define GH_CALL_TYPE_HYPERCALL 2 > +#define GH_CALL_TYPE_SERVICE 3 > +#define GH_CALL_TYPE_SHIFT 14 > +#define GH_CALL_FUNCTION_NUM_MASK 0x3fff A FN_ID is a 32-bit value. Are all 18 high-order bits considered part of the call type? It might be good to specify that explicitly by defining a mask for it. > + > +#define GH_FN_ID(type, num) ((type) << GH_CALL_TYPE_SHIFT | ((num) & GH_CALL_FUNCTION_NUM_MASK)) > + Is there any need for the endianness of these values to be specified? Does Gunyah operate with a well-defined endianness? Is there any chance a VM can run with an endianness different from Gunyah? I see that the arm_smcc_* structures are defined without endianness. (Sorry if these are dumb questions.) > +#define GH_SERVICE(fn) ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \ > + ARM_SMCCC_OWNER_VENDOR_HYP, \ > + GH_FN_ID(GH_CALL_TYPE_SERVICE, fn)) > + > +#define GH_HYPERCALL_CALL_UID GH_SERVICE(0x3f01) Perhaps 0x3f01 could be defined symbolically. However if this is the only place it's ever used, doing so doesn't add much value (meaning, just do it the way you did). > + > +#define GH_HYPERCALL(fn) ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_64, \ > + ARM_SMCCC_OWNER_VENDOR_HYP, \ > + GH_FN_ID(GH_CALL_TYPE_HYPERCALL, fn)) > + > +#define GH_HYPERCALL_HYP_IDENTIFY GH_HYPERCALL(0x0000) Will there be a growing set of well-known hypervisor call functions? Perhaps 0x0000 should be defined symbolically. (Or not if it's only used here.) > + > +/** > + * gh_hypercall_get_uid() - Returns a UID when running under a Gunyah hypervisor > + * @uid: An array of 4 u32's (u32 uid[4];) > + * > + * Caller should compare the resulting UID to a list of known Gunyah UIDs to > + * confirm that Linux is running as a guest of Gunyah. I presume that, if the returned UID isn't well-known, then no other Gunyah-related calls are meaningful. Is that correct? > + */ > +void gh_hypercall_get_uid(u32 uid[4]) > +{ > + struct arm_smccc_res res; > + > + arm_smccc_1_1_hvc(GH_HYPERCALL_CALL_UID, &res); > + > + uid[0] = res.a0; > + uid[1] = res.a1; > + uid[2] = res.a2; > + uid[3] = res.a3; I see in the definition of struct arm_smccc_res that the four fields are unsigned long values. That differs from the u32 array passed as argument. Are the resource IDs guaranteed to be four 32-bit values? I personally prefer being explicit about the upper 32-bits being discarded (though some don't agree with that convention). > +} > +EXPORT_SYMBOL_GPL(gh_hypercall_get_uid); > + > +/** > + * gh_hypercall_hyp_identify() - Returns build information and feature flags > + * supported by Gunyah. > + * @hyp_identity: filled by the hypercall with the API info and feature flags. > + */ > +void gh_hypercall_hyp_identify(struct gh_hypercall_hyp_identify_resp *hyp_identity) > +{ > + struct arm_smccc_res res; > + > + arm_smccc_1_1_hvc(GH_HYPERCALL_HYP_IDENTIFY, &res); > + > + hyp_identity->api_info = res.a0; > + hyp_identity->flags[0] = res.a1; > + hyp_identity->flags[1] = res.a2; > + hyp_identity->flags[2] = res.a3; > +} > +EXPORT_SYMBOL_GPL(gh_hypercall_hyp_identify); > + > +MODULE_LICENSE("GPL"); > +MODULE_DESCRIPTION("Gunyah Hypervisor Hypercalls"); > diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig > index 87ef258cec64..259dc2be6cad 100644 > --- a/drivers/virt/Kconfig > +++ b/drivers/virt/Kconfig > @@ -52,4 +52,5 @@ source "drivers/virt/coco/efi_secret/Kconfig" > > source "drivers/virt/coco/sev-guest/Kconfig" > > +source "drivers/virt/gunyah/Kconfig" > endif > diff --git a/drivers/virt/gunyah/Kconfig b/drivers/virt/gunyah/Kconfig > new file mode 100644 > index 000000000000..127156a678a6 > --- /dev/null > +++ b/drivers/virt/gunyah/Kconfig > @@ -0,0 +1,12 @@ > +# SPDX-License-Identifier: GPL-2.0-only > + > +config GUNYAH Maybe config QCOM_GUNYAH? Will this ever run on hardware other than Qualcomm's? > + tristate "Gunyah Virtualization drivers" > + depends on ARM64 > + help > + The Gunyah drivers are the helper interfaces that runs in a guest VM s/runs/run/ > + such as basic inter-VM IPC and signaling mechanisms, and higher level > + services such as memory/device sharing, IRQ sharing, and so on. > + > + Say Y/M here to enable the drivers needed to interact in a Gunyah > + virtual environment. > diff --git a/include/linux/gunyah.h b/include/linux/gunyah.h > index 824e20a11d27..2765d2b40198 100644 > --- a/include/linux/gunyah.h > +++ b/include/linux/gunyah.h > @@ -6,6 +6,7 @@ > #ifndef _GUNYAH_H > #define _GUNYAH_H > > +#include <linux/bitfield.h> > #include <linux/types.h> > #include <linux/errno.h> > > @@ -71,4 +72,28 @@ static inline int gh_remap_error(int gh_error) > } > } > > +#define GUNYAH_API_V1 1 > + > +#define GH_API_INFO_API_VERSION_MASK GENMASK_ULL(13, 0) > +#define GH_API_INFO_BIG_ENDIAN BIT_ULL(14) > +#define GH_API_INFO_IS_64BIT BIT_ULL(15) > +#define GH_API_INFO_VARIANT_MASK GENMASK_ULL(63, 56) > + How are the GH_IDENTIFY bits below used? Are they encoded in the three 64-bit flags fields in the response structure? Does that mean only the first of those three is (currently) used? > +#define GH_IDENTIFY_PARTITION_CSPACE BIT_ULL(0) > +#define GH_IDENTIFY_DOORBELL BIT_ULL(1) > +#define GH_IDENTIFY_MSGQUEUE BIT_ULL(2) > +#define GH_IDENTIFY_VIC BIT_ULL(3) > +#define GH_IDENTIFY_VPM BIT_ULL(4) > +#define GH_IDENTIFY_VCPU BIT_ULL(5) > +#define GH_IDENTIFY_MEMEXTENT BIT_ULL(6) > +#define GH_IDENTIFY_TRACE_CTRL BIT_ULL(7) > + > +struct gh_hypercall_hyp_identify_resp { > + u64 api_info; > + u64 flags[3]; > +}; Again I'll ask about endianness. This is a response coming *from* Gunyah. Is it guaranteed to use the same byte order convention as the running operating system (Linux) guest? -Alex > + > +void gh_hypercall_get_uid(u32 uid[4]); > +void gh_hypercall_hyp_identify(struct gh_hypercall_hyp_identify_resp *hyp_identity); > + > #endif _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-01-09 21:36 UTC|newest] Thread overview: 137+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-12-19 22:58 [PATCH v8 00/28] Drivers for gunyah hypervisor Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 01/28] docs: gunyah: Introduce Gunyah Hypervisor Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2023-01-09 21:34 ` Alex Elder 2023-01-09 21:34 ` Alex Elder 2023-01-10 17:54 ` Elliot Berman 2023-01-10 17:54 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 02/28] dt-bindings: Add binding for gunyah hypervisor Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2023-01-09 21:34 ` Alex Elder 2023-01-09 21:34 ` Alex Elder 2022-12-19 22:58 ` [PATCH v8 03/28] gunyah: Common types and error codes for Gunyah hypercalls Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2023-01-09 21:34 ` Alex Elder 2023-01-09 21:34 ` Alex Elder 2023-01-10 17:55 ` Elliot Berman 2023-01-10 17:55 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 04/28] arm64: smccc: Include alternative-macros.h Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2023-01-09 21:34 ` Alex Elder 2023-01-09 21:34 ` Alex Elder 2023-01-10 22:55 ` Elliot Berman 2023-01-10 22:55 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 05/28] virt: gunyah: Add hypercalls to identify Gunyah Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2023-01-09 21:34 ` Alex Elder [this message] 2023-01-09 21:34 ` Alex Elder 2023-01-10 17:56 ` Elliot Berman 2023-01-10 17:56 ` Elliot Berman 2023-01-17 19:20 ` Alex Elder 2023-01-17 19:20 ` Alex Elder 2023-01-17 19:20 ` Alex Elder 2023-01-17 19:20 ` Alex Elder 2023-01-17 22:29 ` Elliot Berman 2023-01-17 22:29 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 06/28] virt: gunyah: Identify hypervisor version Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2023-01-09 21:34 ` Alex Elder 2023-01-09 21:34 ` Alex Elder 2023-01-10 17:56 ` Elliot Berman 2023-01-10 17:56 ` Elliot Berman 2023-01-17 19:21 ` Alex Elder 2023-01-17 19:21 ` Alex Elder 2023-01-17 22:29 ` Elliot Berman 2023-01-17 22:29 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 07/28] mailbox: Allow direct registration to a channel Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2023-01-09 21:34 ` Alex Elder 2023-01-09 21:34 ` Alex Elder 2023-01-10 17:57 ` Elliot Berman 2023-01-10 17:57 ` Elliot Berman 2023-01-17 19:21 ` Alex Elder 2023-01-17 19:21 ` Alex Elder 2022-12-19 22:58 ` [PATCH v8 08/28] virt: gunyah: msgq: Add hypercalls to send and receive messages Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 09/28] mailbox: Add Gunyah message queue mailbox Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2023-01-02 6:13 ` Srivatsa Vaddagiri 2023-01-02 6:13 ` Srivatsa Vaddagiri 2023-01-04 0:32 ` Elliot Berman 2023-01-04 0:32 ` Elliot Berman 2023-01-09 21:34 ` Alex Elder 2023-01-09 21:34 ` Alex Elder 2023-01-10 18:16 ` Elliot Berman 2023-01-10 18:16 ` Elliot Berman 2023-01-17 19:21 ` Alex Elder 2023-01-17 19:21 ` Alex Elder 2022-12-19 22:58 ` [PATCH v8 10/28] gunyah: rsc_mgr: Add resource manager RPC core Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2023-01-17 22:33 ` Alex Elder 2023-01-17 22:33 ` Alex Elder 2023-01-20 23:18 ` Elliot Berman 2023-01-20 23:18 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 11/28] gunyah: rsc_mgr: Add VM lifecycle RPC Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2023-01-09 7:13 ` Srivatsa Vaddagiri 2023-01-09 7:13 ` Srivatsa Vaddagiri 2023-01-09 18:51 ` Elliot Berman 2023-01-09 18:51 ` Elliot Berman 2023-01-18 18:26 ` Alex Elder 2023-01-18 18:26 ` Alex Elder 2023-01-20 1:31 ` Elliot Berman 2023-01-20 1:31 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 12/28] gunyah: vm_mgr: Introduce basic VM Manager Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2023-01-09 9:05 ` Srivatsa Vaddagiri 2023-01-09 9:05 ` Srivatsa Vaddagiri 2023-01-09 19:38 ` Elliot Berman 2023-01-09 19:38 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 13/28] gunyah: rsc_mgr: Add RPC for sharing memory Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2023-01-16 8:45 ` Srivatsa Vaddagiri 2023-01-16 8:45 ` Srivatsa Vaddagiri 2022-12-19 22:58 ` [PATCH v8 14/28] gunyah: vm_mgr: Add/remove user memory regions Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2023-01-20 5:34 ` Srivatsa Vaddagiri 2023-01-20 5:34 ` Srivatsa Vaddagiri 2022-12-19 22:58 ` [PATCH v8 15/28] gunyah: vm_mgr: Add ioctls to support basic non-proxy VM boot Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 16/28] samples: Add sample userspace Gunyah VM Manager Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 17/28] gunyah: rsc_mgr: Add platform ops on mem_lend/mem_reclaim Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 18/28] firmware: qcom_scm: Use fixed width src vm bitmap Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 19/28] firmware: qcom_scm: Register Gunyah platform ops Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2022-12-23 17:21 ` kernel test robot 2022-12-19 22:58 ` [PATCH v8 20/28] docs: gunyah: Document Gunyah VM Manager Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 21/28] virt: gunyah: Translate gh_rm_hyp_resource into gunyah_resource Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 22/28] gunyah: vm_mgr: Add framework to add VM Functions Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 23/28] virt: gunyah: Add resource tickets Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 24/28] virt: gunyah: Add IO handlers Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 25/28] virt: gunyah: Add proxy-scheduled vCPUs Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 26/28] virt: gunyah: Add hypercalls for sending doorbell Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2022-12-19 22:58 ` [PATCH v8 27/28] virt: gunyah: Add irqfd interface Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2022-12-21 17:00 ` kernel test robot 2022-12-19 22:58 ` [PATCH v8 28/28] virt: gunyah: Add ioeventfd Elliot Berman 2022-12-19 22:58 ` Elliot Berman 2023-01-09 21:34 ` [PATCH v8 00/28] Drivers for gunyah hypervisor Alex Elder 2023-01-09 21:34 ` Alex Elder 2023-01-10 17:54 ` Elliot Berman 2023-01-10 17:54 ` Elliot Berman 2023-01-10 21:47 ` Elliot Berman 2023-01-10 21:47 ` Elliot Berman 2023-01-17 19:20 ` Alex Elder 2023-01-17 19:20 ` Alex Elder
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=63bbc640-9b0c-95af-3d35-291da0323db3@linaro.org \ --to=elder@linaro.org \ --cc=arnd@arndb.de \ --cc=bagasdotme@gmail.com \ --cc=catalin.marinas@arm.com \ --cc=corbet@lwn.net \ --cc=devicetree@vger.kernel.org \ --cc=dmitry.baryshkov@linaro.org \ --cc=gregkh@linuxfoundation.org \ --cc=jassisinghbrar@gmail.com \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lpieralisi@kernel.org \ --cc=mark.rutland@arm.com \ --cc=quic_bjorande@quicinc.com \ --cc=quic_cvanscha@quicinc.com \ --cc=quic_eberman@quicinc.com \ --cc=quic_mnalajal@quicinc.com \ --cc=quic_pheragu@quicinc.com \ --cc=quic_svaddagi@quicinc.com \ --cc=quic_tsoni@quicinc.com \ --cc=robh+dt@kernel.org \ --cc=sudeep.holla@arm.com \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.