It will print error information inside memcpy_s if
the parameteter is invalid, the caller can not check
the return value for memcpy_s/strcpy_s/strncpy_s
code like this:
int a(void) {
return 0;
}
int b(void){
a();
}
fix as follow:
int a(void) {
return 0;
}
int b(void){
(void)a();
}
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
No need to check the return value for memset
code like this:
int a(void) {
return 0;
}
int b(void){
a();
}
fix as follow:
int a(void) {
return 0;
}
int b(void){
(void)a();
}
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
In the hypervisor, virtual cpu id is defined as "int" or "uint32_t"
type in the hypervisor. So there are some sign conversion issues
about virtual cpu id (vcpu_id) reported by static analysis tool.
Sign conversion violates the rules of MISRA C:2012.
BTW, virtual cpu id has different names (vcpu_id, cpu_id, logical_id)
for different modules of HV, its type is defined as "int" or "uint32_t"
in the HV. cpu_id type and logical_id type clean up will be done in
other patchs.
V1-->V2:
More clean up the type of vcpu id;
"%hu" is for vcpu id in the print function.
Signed-off-by: Xiangyang Wu <xiangyang.wu@intel.com>
Misra C required signed/unsigned conversion with cast.
V1->V2:
a.split patch to patch series
V2->V3:
a.change the uint64_t type numeric constant's suffix from U to UL
Signed-off-by: Huihuang Shi <huihuang.shi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
The local variable type should be transfer to non-basic type,
chaned it to length-prefix(uint32_t,int32_t ...) type.
Char *type or char array type which used to pointer a string
will be keeped.
V1->V2 add extra comments.
Signed-off-by: Huihuang Shi <huihuang.shi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
MISRA C explicit required expression should be boolean when
in branch statements (if,while...).
Signed-off-by: Huihuang Shi <huihuang.shi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
In current code, sos/uos bsp can only start from 64bit mode.
For sbl platform:
This patch start sos bsp from protected mode by default.
CONFIG_START_VM0_BSP_64BIT is defined to allow start sos bsp
from 64bit mode. If a config CONFIG_START_VM0_BSP_64BIT
defined in config file, then sos bsp will start from 64bit mode.
This patch start uos bsp from real mode, which needs the integration
of virtual bootloader (vsbl).
For uefi platform:
This patch sets sos bsp vcpu mode according to the uefi context.
This patch starts uos bsp from protected mode, because vsbl is not ready
to publish for uefi platform yet. After vsbl is ready, can change to
start uos bsp from real mode.
Signed-off-by: Binbin Wu <binbin.wu@intel.com>
Reviewed-by: Eddie Dong <eddie.dong@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Acked-by: Xu, Anthony <anthony.xu@intel.com>
According to the comments in hypervisor:
" This file includes config header file "bsp_cfg.h" and other
hypervisor used header files.
It should be included in all the source files."
this patch includes all common header files in hypervisor.h
then removes other redundant inclusions
Signed-off-by: Zide Chen <zide.chen@intel.com>
We removed '\n' in bootargs file so there is no '\n' attached
to cmdline when stitching ACRN. Then we don't need to deal with
it in ACRN.
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Eddie Dong <Eddie.dong@intel.com>
adding "hugepagesz=1G" and "hugepages=X" into SOS cmdline, for X, current
strategy is making it equal
e820_mem.total_mem_size -CONFIG_REMAIN_1G_PAGES
if CONFIG_REMAIN_1G_PAGES is not set, it will use 3 by default.
CONFIG_CMA is added to indicate using cma cmdline option for SOS kernel,
by default system will use hugetlb cmdline option if no CONFIG_CMA defined.
Signed-off-by: Jason Chen CJ <jason.cj.chen@intel.com>
Acked-by: Xu, Anthony <anthony.xu@intel.com>
Before this patch, guest temporary page tables were generated by hardcode
at compile time, HV will copy this page tables to guest before guest
launch.
This patch creates temporary page tables at runtime for the range of 0~4G,
and create page tables to cover new range(511G~511G+16M) with trusty
requirement.
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
According to the explaination for pref_address
in Documentation/x86/boot.txt, a relocating bootloader
should attempt to load kernel at pref_address if possible.
But due to a non-relocatable kernel will unconditionally
move itself and to run at perf address, no need to copy
kernel to perf_address by bootloader.
Signed-off-by: Zheng, Gen <gen.zheng@intel.com>
