Messages in this thread | | | Date | Thu, 16 Feb 2023 09:18:13 -0800 | Subject | Re: [PATCH v10 09/26] gunyah: rsc_mgr: Add VM lifecycle RPC | From | Elliot Berman <> |
| |
On 2/15/2023 10:39 PM, Greg Kroah-Hartman wrote: > On Tue, Feb 14, 2023 at 01:23:42PM -0800, 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 | 45 ++++++ >> drivers/virt/gunyah/rsc_mgr_rpc.c | 226 ++++++++++++++++++++++++++++++ >> include/linux/gunyah_rsc_mgr.h | 73 ++++++++++ >> 4 files changed, 345 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 d4e799a7526f..7406237bc66d 100644 >> --- a/drivers/virt/gunyah/rsc_mgr.h >> +++ b/drivers/virt/gunyah/rsc_mgr.h >> @@ -74,4 +74,49 @@ 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_RESET 0x56000006 >> +#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_rm_vm_common_vmid_req { >> + __le16 vmid; >> + __le16 reserved0; > > reserved for what? What is a valid value for this field? Should it be > checked for 0?
This struct is transmitted "over the wire" and RM makes all of its structures 4-byte aligned. The reserved fields are padding for this alignment and will be zero but don't need to be checked. Linux initializes the reserved fields to zero.
> > Same with other "reserved0" fields in this file. > > >> +} __packed; >> + >> +/* Call: VM_ALLOC */ >> +struct gh_rm_vm_alloc_vmid_resp { >> + __le16 vmid; >> + __le16 reserved0; >> +} __packed; >> + >> +/* Call: VM_STOP */ >> +struct gh_rm_vm_stop_req { >> + __le16 vmid; >> +#define GH_RM_VM_STOP_FLAG_FORCE_STOP BIT(0) >> + u8 flags; >> + u8 reserved; > > Why just "reserved" and not "reserved0"? Naming is hard :( >
Some fields have multiple reserved fields. I'll clean up so "reserved0" only appears when there are multiple padding fields.
Thanks, Elliot
| |