VM Name length is restricted to 32 characters. kata creates
a VM name with GUID added as a part of VM name making it around
80 characters. So increasing this size to 128.
v1->v2:
It turns out that MAX_VM_OS_NAME_LEN usage in DM and HV are for
different use cases. So removing the macro from acrn_common.h.
Definied macro MAX_VMNAME_LEN for DM purposes in dm.h. Retaining
original macron name MAX_VM_OS_NAME_LEN for HV purposes but defined
in vm_config.h.
Tracked-On: #3138
Signed-off-by: Vijay Dhanraj <vijay.dhanraj@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
This patch adds support for new acrnctl command blkrescan.
Purpose: To add a virtio-blk device to guest VM after launch.
Use case:
1. Anticipate number of block devices that will be needed
and add empty backend file while launching VM.
e.g: -s 5, virtio-blk,nodisk
2. Use the following acrnctl command to trigger
a rescan of virtio-blk device by guest VM, to
revalidate and update the backend file.
“acrnctl blkrescan VMname slot,newfilepath”
v5 -> v6:
- Removed unsed #define
- Reduced the size of param len of blkrescan command
from 512 to 256.
v2 -> v5:
- No change
v1 -> v2:
- Renamed the acrnctl command and APIs from diskplug
to blkrescan.
- Split the patch into two. This corresponds to
changes in tools.
Tracked-On: #3051
Signed-off-by: Vijay Dhanraj <vijay.dhanraj@intel.com>
Reviewed-by: Yu Wang <yu1.wang@intel.com>
There are several duplicate definitions for check_dir, it can check or create directory at will. However, only acrnd and dm monitor can create the directory. This commit fixs the possibility of creating directory at will by no permission process, which adds a param flags to conctrl if it should create the directory. By the way, this commit collates related MACRO into the same file , deletes the duplicate definitions in another files and fixs some format issues.
Tracked-On: #2886
Signed-off-by: Mao Jiang <maox.jiang@intel.com>
Acked-by: Yan, Like <like.yan@intel.com>
'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>
