'acrnctl start vmname' use a cmd buffer with a sizeof 128 bytes,
cmd[128] buffer will be truncated, when vmnane size is bigger than
29 bytes. In that situation, vmnane size still smaller than
MAX_VM_OS_NAME_LEN, so it should be fixed.
Macro PATH_LEN is useful to determine the cmd[] buffer length, so move
it from acrn_mngr.c into acrn_mngr.h
Tracked-On: #2851
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
Reviewed-by: Yan Like <like.yan@intel.com>
Acked-by: Yin Fengwei <fengwei.yin@intel.com>
When run 'acrnctl add launch_script.sh', vmname will be detected from
the launch script and stored in vmmngr_struct.name[MAX_VM_OS_NAME_LEN],
so vmname should not be longer than MAX_VM_OS_NAME_LEN.
Tracked-On: #2851
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
pdebug just provide information about function name and source code line number.
From debug point of view, it is better to give developer more detailed err msg.
Tracked-On: #2716
Signed-off-by: Kaige Fu <kaige.fu@intel.com>
Acked-by: Yan, Like <like.yan@intel.com>
DM need to know wakeup reason when resume the VM, so
vm_resume(char *name) is updated to vm_resume(char *name, unsigned reason),
in acrn_vm_ops.c
Acked-by: Yan Like <like.yan@intel.com>
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
acrn-manager message structure has a flexible member
payload[0], that risks to out-of-boundary memory access,
and usage of uninitialized variable.
And the req/ack message pairs has various types, which
extend mngr_msg. mngr_send_msg() requires programmer cast
the type of input messages to struct mngr_msg, that is
inconvenient.
We replace payload[0] with an union, which contains all
payload data. So that type cast for mngr_send_msg() is no
longer needed. And we can avoid potential out-of-boundary
memory accessing and using of uninitialized variable
Acked-by: Yan Like <like.yan@intel.com>
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
There are some problems to use VM operations in a deamon process,
such as Acrnd. the list_vm() does not return VM informations, it
just print VM information to stdio, so we have get_vm_list()
to get VM list head vmngr_head; get_vm_list() always creates a
new fresh vm list every time, and must use put_vm_list() to delete
old list. So Acrnd need to create and destroy vm list frequently.
In fact we just need the vmngr_head to be an extern variable. And
to make it refreshable.We can insert new VMs, remove dead ones,
and update their state.
Reviewed-by: Yan Like <like.yan@intel.com>
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
There is a mistake on description for mngr_send_msg() in acrn_mngr.h
We mistake the ack_len to req_len
Acked-by: Eddie Dong <eddie.dong@intel.com>
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
There are some inappropriate descrition related to mngr, like "vmm msg".
Replace all "vmm" with "mngr".
No functional change.
Signed-off-by: Kaige Fu <kaige.fu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
We define messages into three types, accroding to which component is
responsible to handle it:
1. message handled by sos lifecycle service, from vm manager;
2. message handled by vm manager, from sos lifecycle service&dm;
3. message handled by dm, from vm manager.
Reviewed-by: Kaige Fu <kaige.fu@intel.com>
Reviewed-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Wang, Yu <yu1.wang@intel.com>
signed-off-by: Yan Like <like.yan@intel.com>
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
Add lib to help IPC between components, including SOS lifecycle service,
acrn manager and devicemodule.
Following helper functions are included:
int mngr_open_un() - create a descripter for vm management IPC
void mngr_close() - close descripter and release the resouces
int mngr_add_handler() - add a handler for message specified by msg
int mngr_send_msg() - send a message and wait for ack
Reviewed-by: Kaige Fu <kaige.fu@intel.com>
Reviewed-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Wang, Yu <yu1.wang@intel.com>
Sigbed-off-by: Yan Like <like.yan@intel.com>
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
