From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> To: Elliot Berman <quic_eberman@quicinc.com>, Bjorn Andersson <quic_bjorande@quicinc.com>, Alex Elder <elder@linaro.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>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, 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>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>, Jassi Brar <jassisinghbrar@gmail.com>, Sudeep Holla <sudeep.holla@arm.com>, 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 Subject: Re: [PATCH v9 10/27] gunyah: rsc_mgr: Add VM lifecycle RPC Date: Thu, 2 Feb 2023 12:46:14 +0000 [thread overview] Message-ID: <4db1c760-10d9-3a22-106a-dda141dd5381@linaro.org> (raw) In-Reply-To: <20230120224627.4053418-11-quic_eberman@quicinc.com> On 20/01/2023 22:46, Elliot Berman wrote: > Add Gunyah Resource Manager RPC to launch an unauthenticated VM. > > Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > --- > drivers/virt/gunyah/Makefile | 2 +- > drivers/virt/gunyah/rsc_mgr.h | 36 +++++ > drivers/virt/gunyah/rsc_mgr_rpc.c | 238 ++++++++++++++++++++++++++++++ > include/linux/gunyah_rsc_mgr.h | 55 +++++++ > 4 files changed, 330 insertions(+), 1 deletion(-) > create mode 100644 drivers/virt/gunyah/rsc_mgr_rpc.c > > diff --git a/drivers/virt/gunyah/Makefile b/drivers/virt/gunyah/Makefile > index cc864ff5abbb..de29769f2f3f 100644 > --- a/drivers/virt/gunyah/Makefile > +++ b/drivers/virt/gunyah/Makefile > @@ -2,5 +2,5 @@ > > obj-$(CONFIG_GUNYAH) += gunyah.o > > -gunyah_rsc_mgr-y += rsc_mgr.o > +gunyah_rsc_mgr-y += rsc_mgr.o rsc_mgr_rpc.o > obj-$(CONFIG_GUNYAH) += gunyah_rsc_mgr.o > diff --git a/drivers/virt/gunyah/rsc_mgr.h b/drivers/virt/gunyah/rsc_mgr.h > index 824749e63a54..2f12f31a2ea6 100644 > --- a/drivers/virt/gunyah/rsc_mgr.h > +++ b/drivers/virt/gunyah/rsc_mgr.h > @@ -68,4 +68,40 @@ struct gh_rm; > int gh_rm_call(struct gh_rm *rsc_mgr, u32 message_id, void *req_buff, size_t req_buff_size, > void **resp_buf, size_t *resp_buff_size); > > +/* Message IDs: VM Management */ > +#define GH_RM_RPC_VM_ALLOC_VMID 0x56000001 > +#define GH_RM_RPC_VM_DEALLOC_VMID 0x56000002 > +#define GH_RM_RPC_VM_START 0x56000004 > +#define GH_RM_RPC_VM_STOP 0x56000005 > +#define GH_RM_RPC_VM_CONFIG_IMAGE 0x56000009 > +#define GH_RM_RPC_VM_INIT 0x5600000B > +#define GH_RM_RPC_VM_GET_HYP_RESOURCES 0x56000020 > +#define GH_RM_RPC_VM_GET_VMID 0x56000024 > + > +struct gh_vm_common_vmid_req { > + __le16 vmid; > + __le16 reserved0; > +} __packed; > + > +/* Call: VM_STOP */ > +struct gh_vm_stop_req { > + __le16 vmid; > + u8 flags; /* currently not used */ > + u8 reserved; > + __le32 stop_reason; /* currently not used */ > +} __packed; > + > +/* Call: VM_CONFIG_IMAGE */ > +struct gh_vm_config_image_req { > + __le16 vmid; > + __le16 auth_mech; > + __le32 mem_handle; > + __le64 image_offset; > + __le64 image_size; > + __le64 dtb_offset; > + __le64 dtb_size; > +} __packed; > + > +/* Call: GET_HYP_RESOURCES */ > + > #endif > diff --git a/drivers/virt/gunyah/rsc_mgr_rpc.c b/drivers/virt/gunyah/rsc_mgr_rpc.c > new file mode 100644 > index 000000000000..b6935dfac1fe > --- /dev/null > +++ b/drivers/virt/gunyah/rsc_mgr_rpc.c > @@ -0,0 +1,238 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved. > + */ > + > +#include <linux/gunyah_rsc_mgr.h> > + > +#include "rsc_mgr.h" > + > +/* > + * Several RM calls take only a VMID as a parameter and give only standard > + * response back. Deduplicate boilerplate code by using this common call. > + */ > +static int gh_rm_common_vmid_call(struct gh_rm *rm, u32 message_id, u16 vmid) > +{ > + void *resp; > + struct gh_vm_common_vmid_req req_payload = { > + .vmid = cpu_to_le16(vmid), > + }; > + size_t resp_size; > + int ret; > + > + ret = gh_rm_call(rm, message_id, &req_payload, sizeof(req_payload), &resp, &resp_size); > + if (!ret && resp_size) { Am struggling to understand these type of checks in success case, when a command is not expecting any response why are we checking for response here, This sounds like a bug in either RM or hypervisor. Or Is this something that happens due to some firmware behaviour? Could you elobrate on this. > + pr_warn("Unexpected payload size: %ld Expected: 0", resp_size); > + dump_stack(); > + kfree(resp); > + return -EBADMSG; > + } > + > + return ret; > +} > + > +/** > + * gh_rm_alloc_vmid() - Allocate a new VM in Gunyah. Returns the VM identifier. > + * @vmid: Use GH_VMID_INVAL or GH_VMID_SELF (0) to dynamically allocate a VM. A reserved VMID can > + * be supplied to request allocation of a platform-defined VM. > + * > + * Returns - the allocated VMID or negative value on error > + */ > +int gh_rm_alloc_vmid(struct gh_rm *rm, u16 vmid) > +{ > + void *resp; > + struct gh_vm_common_vmid_req req_payload = { > + .vmid = cpu_to_le16(vmid), we pass vmid that is recevied here. > + }; > + struct gh_vm_alloc_vmid_resp *resp_payload; > + size_t resp_size; > + int ret; > + > + if (vmid == GH_VMID_INVAL) > + vmid = 0; then we change this to 0. > + > + ret = gh_rm_call(rm, GH_RM_RPC_VM_ALLOC_VMID, &req_payload, sizeof(req_payload), &resp, > + &resp_size); > + if (ret) > + return ret; > + > + if (!vmid) { then here we check agaist zero. Why not just do if (vmid == GH_VMID_INVAL || vmid == GH_VMID_SELF) this will make core more reader friendly and match to what is in kerneldoc. > + if (resp_size != sizeof(*resp_payload)) { > + pr_warn("%s: unexpected payload size: %ld Expected: %ld", __func__, > + resp_size, sizeof(*resp_payload)); > + ret = -EBADMSG; > + } else { > + resp_payload = resp; > + ret = le16_to_cpu(resp_payload->vmid); > + } > + } > + kfree(resp); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(gh_rm_alloc_vmid); > + > +/** > + * gh_rm_dealloc_vmid() - Dispose the VMID > + * @vmid: VM identifier > + */ > +int gh_rm_dealloc_vmid(struct gh_rm *rm, u16 vmid) > +{ > + return gh_rm_common_vmid_call(rm, GH_RM_RPC_VM_DEALLOC_VMID, vmid); > +} > +EXPORT_SYMBOL_GPL(gh_rm_dealloc_vmid); > + > +/** > + * gh_rm_vm_start() - Move the VM into "ready to run" state > + * @vmid: VM identifier > + * > + * On VMs which use proxy scheduling, vcpu_run is needed to actually run the VM. > + * On VMs which use Gunyah's scheduling, the vCPUs start executing in accordance with Gunyah > + * scheduling policies. > + */ > +int gh_rm_vm_start(struct gh_rm *rm, u16 vmid) > +{ > + return gh_rm_common_vmid_call(rm, GH_RM_RPC_VM_START, vmid); > +} > +EXPORT_SYMBOL_GPL(gh_rm_vm_start); > + > +/** > + * gh_rm_vm_stop() - Send a request to Resource Manager VM to stop a VM. > + * @vmid: VM identifier > + * > + * Returns - 0 on success; negative value on failure > + */ > +int gh_rm_vm_stop(struct gh_rm *rm, u16 vmid) > +{ > + struct gh_vm_stop_req req_payload = { > + .vmid = cpu_to_le16(vmid), > + }; > + void *resp; > + size_t resp_size; > + int ret; > + > + ret = gh_rm_call(rm, GH_RM_RPC_VM_STOP, &req_payload, sizeof(req_payload), > + &resp, &resp_size); > + if (!ret && resp_size) { same comment as the first one. > + pr_warn("%s: unexpected payload size: %ld Expected: 0", __func__, resp_size); > + kfree(resp); > + return -EBADMSG; > + } > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(gh_rm_vm_stop); > + > +int gh_rm_vm_configure(struct gh_rm *rm, u16 vmid, enum gh_rm_vm_auth_mechanism auth_mechanism, > + u32 mem_handle, u64 image_offset, u64 image_size, u64 dtb_offset, u64 dtb_size) > +{ > + struct gh_vm_config_image_req req_payload = { 0 }; > + void *resp; > + size_t resp_size; > + int ret; > + > + req_payload.vmid = cpu_to_le16(vmid); > + req_payload.auth_mech = cpu_to_le16(auth_mechanism); > + req_payload.mem_handle = cpu_to_le32(mem_handle); > + req_payload.image_offset = cpu_to_le64(image_offset); > + req_payload.image_size = cpu_to_le64(image_size); > + req_payload.dtb_offset = cpu_to_le64(dtb_offset); > + req_payload.dtb_size = cpu_to_le64(dtb_size); > + > + ret = gh_rm_call(rm, GH_RM_RPC_VM_CONFIG_IMAGE, &req_payload, sizeof(req_payload), > + &resp, &resp_size); > + if (!ret && resp_size) { same comment as the first one. > + pr_warn("%s: unexpected payload size: %ld Expected: 0", __func__, resp_size); > + kfree(resp); > + return -EBADMSG; > + } > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(gh_rm_vm_configure); > + > +/** > + * gh_rm_vm_init() - Move the VM to initialized state. > + * @vmid: VM identifier > + * > + * RM will allocate needed resources for the VM. After gh_rm_vm_init, gh_rm_get_hyp_resources() > + * can be called to learn of the capabilities we can use with the new VM. > + * > + * Returns - 0 on success; negative value on failure > + */ > +int gh_rm_vm_init(struct gh_rm *rm, u16 vmid) > +{ > + return gh_rm_common_vmid_call(rm, GH_RM_RPC_VM_INIT, vmid); > +} > +EXPORT_SYMBOL_GPL(gh_rm_vm_init); > + > +/** > + * gh_rm_get_hyp_resources() - Retrieve hypervisor resources (capabilities) associated with a VM > + * @vmid: VMID of the other VM to get the resources of > + * @resources: Set by gh_rm_get_hyp_resources and contains the returned hypervisor resources. > + * > + * Returns - 0 on success; negative value on failure > + */ > +int gh_rm_get_hyp_resources(struct gh_rm *rm, u16 vmid, > + struct gh_rm_hyp_resources **resources) > +{ > + struct gh_rm_hyp_resources *resp; > + size_t resp_size; > + int ret; > + struct gh_vm_common_vmid_req req_payload = { > + .vmid = cpu_to_le16(vmid), > + }; > + > + ret = gh_rm_call(rm, GH_RM_RPC_VM_GET_HYP_RESOURCES, > + &req_payload, sizeof(req_payload), > + (void **)&resp, &resp_size); we can go upto 100 chars. > + if (ret) > + return ret; > + > + if (!resp_size) > + return -EBADMSG; This is again another check that falls under the first category, how can a command pass and return incorrect responses? Or are we doing to many unnecessary checks? > + > + if (resp_size < struct_size(resp, entries, 0) || > + resp_size != struct_size(resp, entries, le32_to_cpu(resp->n_entries))) { > + kfree(resp); > + return -EBADMSG; > + } > + > + *resources = resp; > + return 0; > +} > +EXPORT_SYMBOL_GPL(gh_rm_get_hyp_resources); > + > +/** > + * gh_rm_get_vmid() - Retrieve VMID of this virtual machine > + * @vmid: Filled with the VMID of this VM > + */ > +int gh_rm_get_vmid(struct gh_rm *rm, u16 *vmid) > +{ > + static u16 cached_vmid = GH_VMID_INVAL; > + __le16 *resp; > + size_t resp_size; > + int ret; > + > + if (cached_vmid != GH_VMID_INVAL) { > + *vmid = cached_vmid; > + return 0; > + } > + > + ret = gh_rm_call(rm, GH_RM_RPC_VM_GET_VMID, NULL, 0, (void **)&resp, &resp_size); > + if (ret) > + return ret; > + > + if (resp_size != sizeof(*resp)) { > + pr_warn("%s: unexpected payload size: %ld Expected: %ld", __func__, > + resp_size, sizeof(*resp)); > + ret = -EBADMSG; > + goto out; > + } > + > + *vmid = cached_vmid = le16_to_cpu(*resp); > +out: > + kfree(resp); > + return ret; > +} > +EXPORT_SYMBOL_GPL(gh_rm_get_vmid);
WARNING: multiple messages have this Message-ID (diff)
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> To: Elliot Berman <quic_eberman@quicinc.com>, Bjorn Andersson <quic_bjorande@quicinc.com>, Alex Elder <elder@linaro.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>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, 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>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>, Jassi Brar <jassisinghbrar@gmail.com>, Sudeep Holla <sudeep.holla@arm.com>, 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 Subject: Re: [PATCH v9 10/27] gunyah: rsc_mgr: Add VM lifecycle RPC Date: Thu, 2 Feb 2023 12:46:14 +0000 [thread overview] Message-ID: <4db1c760-10d9-3a22-106a-dda141dd5381@linaro.org> (raw) In-Reply-To: <20230120224627.4053418-11-quic_eberman@quicinc.com> On 20/01/2023 22:46, Elliot Berman wrote: > Add Gunyah Resource Manager RPC to launch an unauthenticated VM. > > Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > --- > drivers/virt/gunyah/Makefile | 2 +- > drivers/virt/gunyah/rsc_mgr.h | 36 +++++ > drivers/virt/gunyah/rsc_mgr_rpc.c | 238 ++++++++++++++++++++++++++++++ > include/linux/gunyah_rsc_mgr.h | 55 +++++++ > 4 files changed, 330 insertions(+), 1 deletion(-) > create mode 100644 drivers/virt/gunyah/rsc_mgr_rpc.c > > diff --git a/drivers/virt/gunyah/Makefile b/drivers/virt/gunyah/Makefile > index cc864ff5abbb..de29769f2f3f 100644 > --- a/drivers/virt/gunyah/Makefile > +++ b/drivers/virt/gunyah/Makefile > @@ -2,5 +2,5 @@ > > obj-$(CONFIG_GUNYAH) += gunyah.o > > -gunyah_rsc_mgr-y += rsc_mgr.o > +gunyah_rsc_mgr-y += rsc_mgr.o rsc_mgr_rpc.o > obj-$(CONFIG_GUNYAH) += gunyah_rsc_mgr.o > diff --git a/drivers/virt/gunyah/rsc_mgr.h b/drivers/virt/gunyah/rsc_mgr.h > index 824749e63a54..2f12f31a2ea6 100644 > --- a/drivers/virt/gunyah/rsc_mgr.h > +++ b/drivers/virt/gunyah/rsc_mgr.h > @@ -68,4 +68,40 @@ struct gh_rm; > int gh_rm_call(struct gh_rm *rsc_mgr, u32 message_id, void *req_buff, size_t req_buff_size, > void **resp_buf, size_t *resp_buff_size); > > +/* Message IDs: VM Management */ > +#define GH_RM_RPC_VM_ALLOC_VMID 0x56000001 > +#define GH_RM_RPC_VM_DEALLOC_VMID 0x56000002 > +#define GH_RM_RPC_VM_START 0x56000004 > +#define GH_RM_RPC_VM_STOP 0x56000005 > +#define GH_RM_RPC_VM_CONFIG_IMAGE 0x56000009 > +#define GH_RM_RPC_VM_INIT 0x5600000B > +#define GH_RM_RPC_VM_GET_HYP_RESOURCES 0x56000020 > +#define GH_RM_RPC_VM_GET_VMID 0x56000024 > + > +struct gh_vm_common_vmid_req { > + __le16 vmid; > + __le16 reserved0; > +} __packed; > + > +/* Call: VM_STOP */ > +struct gh_vm_stop_req { > + __le16 vmid; > + u8 flags; /* currently not used */ > + u8 reserved; > + __le32 stop_reason; /* currently not used */ > +} __packed; > + > +/* Call: VM_CONFIG_IMAGE */ > +struct gh_vm_config_image_req { > + __le16 vmid; > + __le16 auth_mech; > + __le32 mem_handle; > + __le64 image_offset; > + __le64 image_size; > + __le64 dtb_offset; > + __le64 dtb_size; > +} __packed; > + > +/* Call: GET_HYP_RESOURCES */ > + > #endif > diff --git a/drivers/virt/gunyah/rsc_mgr_rpc.c b/drivers/virt/gunyah/rsc_mgr_rpc.c > new file mode 100644 > index 000000000000..b6935dfac1fe > --- /dev/null > +++ b/drivers/virt/gunyah/rsc_mgr_rpc.c > @@ -0,0 +1,238 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved. > + */ > + > +#include <linux/gunyah_rsc_mgr.h> > + > +#include "rsc_mgr.h" > + > +/* > + * Several RM calls take only a VMID as a parameter and give only standard > + * response back. Deduplicate boilerplate code by using this common call. > + */ > +static int gh_rm_common_vmid_call(struct gh_rm *rm, u32 message_id, u16 vmid) > +{ > + void *resp; > + struct gh_vm_common_vmid_req req_payload = { > + .vmid = cpu_to_le16(vmid), > + }; > + size_t resp_size; > + int ret; > + > + ret = gh_rm_call(rm, message_id, &req_payload, sizeof(req_payload), &resp, &resp_size); > + if (!ret && resp_size) { Am struggling to understand these type of checks in success case, when a command is not expecting any response why are we checking for response here, This sounds like a bug in either RM or hypervisor. Or Is this something that happens due to some firmware behaviour? Could you elobrate on this. > + pr_warn("Unexpected payload size: %ld Expected: 0", resp_size); > + dump_stack(); > + kfree(resp); > + return -EBADMSG; > + } > + > + return ret; > +} > + > +/** > + * gh_rm_alloc_vmid() - Allocate a new VM in Gunyah. Returns the VM identifier. > + * @vmid: Use GH_VMID_INVAL or GH_VMID_SELF (0) to dynamically allocate a VM. A reserved VMID can > + * be supplied to request allocation of a platform-defined VM. > + * > + * Returns - the allocated VMID or negative value on error > + */ > +int gh_rm_alloc_vmid(struct gh_rm *rm, u16 vmid) > +{ > + void *resp; > + struct gh_vm_common_vmid_req req_payload = { > + .vmid = cpu_to_le16(vmid), we pass vmid that is recevied here. > + }; > + struct gh_vm_alloc_vmid_resp *resp_payload; > + size_t resp_size; > + int ret; > + > + if (vmid == GH_VMID_INVAL) > + vmid = 0; then we change this to 0. > + > + ret = gh_rm_call(rm, GH_RM_RPC_VM_ALLOC_VMID, &req_payload, sizeof(req_payload), &resp, > + &resp_size); > + if (ret) > + return ret; > + > + if (!vmid) { then here we check agaist zero. Why not just do if (vmid == GH_VMID_INVAL || vmid == GH_VMID_SELF) this will make core more reader friendly and match to what is in kerneldoc. > + if (resp_size != sizeof(*resp_payload)) { > + pr_warn("%s: unexpected payload size: %ld Expected: %ld", __func__, > + resp_size, sizeof(*resp_payload)); > + ret = -EBADMSG; > + } else { > + resp_payload = resp; > + ret = le16_to_cpu(resp_payload->vmid); > + } > + } > + kfree(resp); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(gh_rm_alloc_vmid); > + > +/** > + * gh_rm_dealloc_vmid() - Dispose the VMID > + * @vmid: VM identifier > + */ > +int gh_rm_dealloc_vmid(struct gh_rm *rm, u16 vmid) > +{ > + return gh_rm_common_vmid_call(rm, GH_RM_RPC_VM_DEALLOC_VMID, vmid); > +} > +EXPORT_SYMBOL_GPL(gh_rm_dealloc_vmid); > + > +/** > + * gh_rm_vm_start() - Move the VM into "ready to run" state > + * @vmid: VM identifier > + * > + * On VMs which use proxy scheduling, vcpu_run is needed to actually run the VM. > + * On VMs which use Gunyah's scheduling, the vCPUs start executing in accordance with Gunyah > + * scheduling policies. > + */ > +int gh_rm_vm_start(struct gh_rm *rm, u16 vmid) > +{ > + return gh_rm_common_vmid_call(rm, GH_RM_RPC_VM_START, vmid); > +} > +EXPORT_SYMBOL_GPL(gh_rm_vm_start); > + > +/** > + * gh_rm_vm_stop() - Send a request to Resource Manager VM to stop a VM. > + * @vmid: VM identifier > + * > + * Returns - 0 on success; negative value on failure > + */ > +int gh_rm_vm_stop(struct gh_rm *rm, u16 vmid) > +{ > + struct gh_vm_stop_req req_payload = { > + .vmid = cpu_to_le16(vmid), > + }; > + void *resp; > + size_t resp_size; > + int ret; > + > + ret = gh_rm_call(rm, GH_RM_RPC_VM_STOP, &req_payload, sizeof(req_payload), > + &resp, &resp_size); > + if (!ret && resp_size) { same comment as the first one. > + pr_warn("%s: unexpected payload size: %ld Expected: 0", __func__, resp_size); > + kfree(resp); > + return -EBADMSG; > + } > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(gh_rm_vm_stop); > + > +int gh_rm_vm_configure(struct gh_rm *rm, u16 vmid, enum gh_rm_vm_auth_mechanism auth_mechanism, > + u32 mem_handle, u64 image_offset, u64 image_size, u64 dtb_offset, u64 dtb_size) > +{ > + struct gh_vm_config_image_req req_payload = { 0 }; > + void *resp; > + size_t resp_size; > + int ret; > + > + req_payload.vmid = cpu_to_le16(vmid); > + req_payload.auth_mech = cpu_to_le16(auth_mechanism); > + req_payload.mem_handle = cpu_to_le32(mem_handle); > + req_payload.image_offset = cpu_to_le64(image_offset); > + req_payload.image_size = cpu_to_le64(image_size); > + req_payload.dtb_offset = cpu_to_le64(dtb_offset); > + req_payload.dtb_size = cpu_to_le64(dtb_size); > + > + ret = gh_rm_call(rm, GH_RM_RPC_VM_CONFIG_IMAGE, &req_payload, sizeof(req_payload), > + &resp, &resp_size); > + if (!ret && resp_size) { same comment as the first one. > + pr_warn("%s: unexpected payload size: %ld Expected: 0", __func__, resp_size); > + kfree(resp); > + return -EBADMSG; > + } > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(gh_rm_vm_configure); > + > +/** > + * gh_rm_vm_init() - Move the VM to initialized state. > + * @vmid: VM identifier > + * > + * RM will allocate needed resources for the VM. After gh_rm_vm_init, gh_rm_get_hyp_resources() > + * can be called to learn of the capabilities we can use with the new VM. > + * > + * Returns - 0 on success; negative value on failure > + */ > +int gh_rm_vm_init(struct gh_rm *rm, u16 vmid) > +{ > + return gh_rm_common_vmid_call(rm, GH_RM_RPC_VM_INIT, vmid); > +} > +EXPORT_SYMBOL_GPL(gh_rm_vm_init); > + > +/** > + * gh_rm_get_hyp_resources() - Retrieve hypervisor resources (capabilities) associated with a VM > + * @vmid: VMID of the other VM to get the resources of > + * @resources: Set by gh_rm_get_hyp_resources and contains the returned hypervisor resources. > + * > + * Returns - 0 on success; negative value on failure > + */ > +int gh_rm_get_hyp_resources(struct gh_rm *rm, u16 vmid, > + struct gh_rm_hyp_resources **resources) > +{ > + struct gh_rm_hyp_resources *resp; > + size_t resp_size; > + int ret; > + struct gh_vm_common_vmid_req req_payload = { > + .vmid = cpu_to_le16(vmid), > + }; > + > + ret = gh_rm_call(rm, GH_RM_RPC_VM_GET_HYP_RESOURCES, > + &req_payload, sizeof(req_payload), > + (void **)&resp, &resp_size); we can go upto 100 chars. > + if (ret) > + return ret; > + > + if (!resp_size) > + return -EBADMSG; This is again another check that falls under the first category, how can a command pass and return incorrect responses? Or are we doing to many unnecessary checks? > + > + if (resp_size < struct_size(resp, entries, 0) || > + resp_size != struct_size(resp, entries, le32_to_cpu(resp->n_entries))) { > + kfree(resp); > + return -EBADMSG; > + } > + > + *resources = resp; > + return 0; > +} > +EXPORT_SYMBOL_GPL(gh_rm_get_hyp_resources); > + > +/** > + * gh_rm_get_vmid() - Retrieve VMID of this virtual machine > + * @vmid: Filled with the VMID of this VM > + */ > +int gh_rm_get_vmid(struct gh_rm *rm, u16 *vmid) > +{ > + static u16 cached_vmid = GH_VMID_INVAL; > + __le16 *resp; > + size_t resp_size; > + int ret; > + > + if (cached_vmid != GH_VMID_INVAL) { > + *vmid = cached_vmid; > + return 0; > + } > + > + ret = gh_rm_call(rm, GH_RM_RPC_VM_GET_VMID, NULL, 0, (void **)&resp, &resp_size); > + if (ret) > + return ret; > + > + if (resp_size != sizeof(*resp)) { > + pr_warn("%s: unexpected payload size: %ld Expected: %ld", __func__, > + resp_size, sizeof(*resp)); > + ret = -EBADMSG; > + goto out; > + } > + > + *vmid = cached_vmid = le16_to_cpu(*resp); > +out: > + kfree(resp); > + return ret; > +} > +EXPORT_SYMBOL_GPL(gh_rm_get_vmid); _______________________________________________ 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-02-02 12:47 UTC|newest] Thread overview: 154+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-20 22:45 [PATCH v9 00/27] Drivers for gunyah hypervisor Elliot Berman 2023-01-20 22:45 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 01/27] docs: gunyah: Introduce Gunyah Hypervisor Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 02/27] dt-bindings: Add binding for gunyah hypervisor Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 03/27] gunyah: Common types and error codes for Gunyah hypercalls Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-01-30 9:58 ` Greg Kroah-Hartman 2023-01-30 9:58 ` Greg Kroah-Hartman 2023-01-20 22:46 ` [PATCH v9 04/27] virt: gunyah: Add hypercalls to identify Gunyah Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-01-30 10:01 ` Greg Kroah-Hartman 2023-01-30 10:01 ` Greg Kroah-Hartman 2023-01-30 19:05 ` Elliot Berman 2023-01-30 19:05 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 05/27] virt: gunyah: Identify hypervisor version Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 06/27] mailbox: Allow direct registration to a channel Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 07/27] virt: gunyah: msgq: Add hypercalls to send and receive messages Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-01-31 16:16 ` Srinivas Kandagatla 2023-01-31 16:16 ` Srinivas Kandagatla 2023-01-20 22:46 ` [PATCH v9 08/27] mailbox: Add Gunyah message queue mailbox Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-02-02 9:59 ` Srinivas Kandagatla 2023-02-02 9:59 ` Srinivas Kandagatla 2023-02-06 14:00 ` Alex Elder 2023-02-06 14:00 ` Alex Elder 2023-02-08 20:46 ` Elliot Berman 2023-02-08 20:46 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 09/27] gunyah: rsc_mgr: Add resource manager RPC core Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-02-02 11:53 ` Srinivas Kandagatla 2023-02-02 11:53 ` Srinivas Kandagatla 2023-02-06 14:14 ` Alex Elder 2023-02-06 14:14 ` Alex Elder 2023-01-20 22:46 ` [PATCH v9 10/27] gunyah: rsc_mgr: Add VM lifecycle RPC Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-01-25 6:12 ` Srivatsa Vaddagiri 2023-01-25 6:12 ` Srivatsa Vaddagiri 2023-01-30 21:43 ` Elliot Berman 2023-01-30 21:43 ` Elliot Berman 2023-02-02 12:46 ` Srinivas Kandagatla [this message] 2023-02-02 12:46 ` Srinivas Kandagatla 2023-02-06 15:41 ` Alex Elder 2023-02-06 15:41 ` Alex Elder 2023-02-06 17:38 ` Elliot Berman 2023-02-06 17:38 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 11/27] gunyah: vm_mgr: Introduce basic VM Manager Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-02-02 12:54 ` Srinivas Kandagatla 2023-02-02 12:54 ` Srinivas Kandagatla 2023-02-07 0:36 ` Elliot Berman 2023-02-07 0:36 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 12/27] gunyah: rsc_mgr: Add RPC for sharing memory Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-01-30 10:14 ` Srivatsa Vaddagiri 2023-01-30 10:14 ` Srivatsa Vaddagiri 2023-01-30 21:45 ` Elliot Berman 2023-01-30 21:45 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 13/27] gunyah: vm_mgr: Add/remove user memory regions Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-01-25 13:34 ` Srivatsa Vaddagiri 2023-01-25 13:34 ` Srivatsa Vaddagiri 2023-01-30 21:46 ` Elliot Berman 2023-01-30 21:46 ` Elliot Berman 2023-02-06 16:12 ` Srinivas Kandagatla 2023-02-06 16:12 ` Srinivas Kandagatla 2023-02-06 23:23 ` Elliot Berman 2023-02-06 23:23 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 14/27] gunyah: vm_mgr: Add ioctls to support basic non-proxy VM boot Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-01-30 8:53 ` Srivatsa Vaddagiri 2023-01-30 8:53 ` Srivatsa Vaddagiri 2023-01-30 21:44 ` Elliot Berman 2023-01-30 21:44 ` Elliot Berman 2023-01-30 21:45 ` Elliot Berman 2023-01-30 21:45 ` Elliot Berman 2023-02-07 11:36 ` Srinivas Kandagatla 2023-02-07 11:36 ` Srinivas Kandagatla 2023-02-08 21:04 ` Elliot Berman 2023-02-08 21:04 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 15/27] samples: Add sample userspace Gunyah VM Manager Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 16/27] gunyah: rsc_mgr: Add platform ops on mem_lend/mem_reclaim Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 17/27] firmware: qcom_scm: Use fixed width src vm bitmap Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-03-16 3:21 ` (subset) " Bjorn Andersson 2023-03-16 3:21 ` Bjorn Andersson 2023-03-16 3:21 ` Bjorn Andersson 2023-01-20 22:46 ` [PATCH v9 18/27] firmware: qcom_scm: Register Gunyah platform ops Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-01-31 15:18 ` Srivatsa Vaddagiri 2023-01-31 15:18 ` Srivatsa Vaddagiri 2023-02-07 11:52 ` Srinivas Kandagatla 2023-02-07 11:52 ` Srinivas Kandagatla 2023-02-08 1:06 ` Elliot Berman 2023-02-08 1:06 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 19/27] docs: gunyah: Document Gunyah VM Manager Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 20/27] virt: gunyah: Translate gh_rm_hyp_resource into gunyah_resource Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 21/27] gunyah: vm_mgr: Add framework to add VM Functions Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-02-03 9:37 ` Srivatsa Vaddagiri 2023-02-03 9:37 ` Srivatsa Vaddagiri 2023-02-03 17:56 ` Srivatsa Vaddagiri 2023-02-03 17:56 ` Srivatsa Vaddagiri 2023-02-07 13:15 ` Srinivas Kandagatla 2023-02-07 13:15 ` Srinivas Kandagatla 2023-02-08 19:34 ` Elliot Berman 2023-02-08 19:34 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 22/27] virt: gunyah: Add resource tickets Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-02-06 9:50 ` Srivatsa Vaddagiri 2023-02-06 9:50 ` Srivatsa Vaddagiri 2023-02-06 21:30 ` Elliot Berman 2023-02-06 21:30 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 23/27] virt: gunyah: Add IO handlers Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-02-06 10:46 ` Srivatsa Vaddagiri 2023-02-06 10:46 ` Srivatsa Vaddagiri 2023-02-07 3:59 ` Elliot Berman 2023-02-07 3:59 ` Elliot Berman 2023-02-07 12:19 ` Srivatsa Vaddagiri 2023-02-07 12:19 ` Srivatsa Vaddagiri 2023-01-20 22:46 ` [PATCH v9 24/27] virt: gunyah: Add proxy-scheduled vCPUs Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-02-07 14:43 ` Srinivas Kandagatla 2023-02-07 14:43 ` Srinivas Kandagatla 2023-02-08 18:36 ` Elliot Berman 2023-02-08 18:36 ` Elliot Berman 2023-02-09 10:39 ` Srivatsa Vaddagiri 2023-02-09 10:39 ` Srivatsa Vaddagiri 2023-02-10 6:54 ` Srivatsa Vaddagiri 2023-02-10 6:54 ` Srivatsa Vaddagiri 2023-02-10 17:09 ` Elliot Berman 2023-02-10 17:09 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 25/27] virt: gunyah: Add hypercalls for sending doorbell Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-01-20 22:46 ` [PATCH v9 26/27] virt: gunyah: Add irqfd interface Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-02-07 14:30 ` Srinivas Kandagatla 2023-02-07 14:30 ` Srinivas Kandagatla 2023-02-13 8:11 ` Srivatsa Vaddagiri 2023-02-13 8:11 ` Srivatsa Vaddagiri 2023-01-20 22:46 ` [PATCH v9 27/27] virt: gunyah: Add ioeventfd Elliot Berman 2023-01-20 22:46 ` Elliot Berman 2023-02-07 14:19 ` Srinivas Kandagatla 2023-02-07 14:19 ` Srinivas Kandagatla
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=4db1c760-10d9-3a22-106a-dda141dd5381@linaro.org \ --to=srinivas.kandagatla@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=elder@linaro.org \ --cc=gregkh@linuxfoundation.org \ --cc=jassisinghbrar@gmail.com \ --cc=krzysztof.kozlowski+dt@linaro.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=maz@kernel.org \ --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.