enum cpu state is better than cpu state macro.
V1->V2:
move enum cpu_state under #ifndef ASSEMBLER MACRO to avoid
assembler compiler scan.
Signed-off-by: Huihuang Shi <huihuang.shi@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
- add a commont head file include/common/irq.h, to include the common data
structure and APIs;
- move the common data struct and APIs from arch/x86/irq.h to the common header.
Signed-off-by: Yan, Like <like.yan@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
phys_cpu_num is more popular than phy_cpu_num, update them
through command.
Signed-off-by: Xiangyang Wu <xiangyang.wu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
In the hypervisor, physical cpu id is defined as "int" or "uint32_t"
type in the hypervisor. So there are some sign conversion issues
about physical cpu id (pcpu_id) reported by static analysis tool.
Sign conversion violates the rules of MISRA C:2012.
In this patch, define physical cpu id as "uint16_t" type for all
modules in the hypervisor and change related codes. The valid
range of pcpu_id is 0~65534, INVALID_PCPU_ID is defined to the
invalid pcpu_id for error detection, BROADCAST_PCPU_ID is
broadcast pcpu_id used to notify all valid pcpu.
The type of pcpu_id in the struct vcpu and vcpu_id is "int" type,
this will be fixed in another patch.
V1-->V2:
* Change the type of pcpu_id from uint32_t to uint16_t;
* Define INVALID_PCPU_ID for error detection;
* Define BROADCAST_PCPU_ID to notify all valid pcpu.
V2-->V3:
* Update comments for INVALID_PCPU_ID and BROADCAST_PCPU_ID;
* Update addtional pcpu_id;
* Convert hexadecimals to unsigned to meet the type of pcpu_id;
* Clean up for MIN_PCPU_ID and MAX_PCPU_ID, they will be
defined by configuration.
Note: fix bug in the init_lapic(), the pcpu_id shall be less than 8,
this is constraint by implement in the init_lapic().
Signed-off-by: Xiangyang Wu <xiangyang.wu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
This patch drops "#include <bsp_cfg.h>" and include the generated config.h in
CFLAGS for the configuration data.
Also make sure that all configuration data have the 'CONFIG_' prefix.
v4 -> v5:
* No changes.
v3 -> v4:
* Add '-include config.h' to hypervisor/bsp/uefi/efi/Makefile.
* Update comments mentioning bsp_cfg.h.
v2 -> v3:
* Include config.h on the command line instead of in any header or source to
avoid including config.h multiple times.
* Add config.h as an additional dependency for source compilation.
v1 -> v2:
* No changes.
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Zhao Yakui <yakui.zhao@intel.com>
To handle cpu down/up dynamically, arcn needs to support vmx off/on
dynamically. Following changes is introduced:
vmx_off will be used when down AP. It does:
- vmclear the mapped vcpu
- off vmx.
exec_vmxon_instr is updated to handle start and up AP both. It does
- if vmx was on on AP, load the vmxon_region saved. Otherwise,
allocate vmxon_region.
- if there is mapped vcpu, vmptrld mapped vcpu.
Signed-off-by: Zheng Gen <gen.zheng@intel.com>
Signed-off-by: Yin Fegnwei <fengwei.yin@intel.com>
Acked-by: Eddie Dong <Eddie.dong@intel.com>
Per performance consideration, we don't flush vcpu context when doing
vcpu swithing (because it's only swithing between vcpu and idle).
But when enter S3, we need to call vmclear against all vcpus attached
to APs. We need to know which vcpu is attached with which pcpu.
This patch introduced API to get vcpu mapped to specific pcpu.
Signed-off-by: Yin Fegnwei <fengwei.yin@intel.com>
Acked-by: Eddie Dong <Eddie.dong@intel.com>
The current implementation of per_cpu relies on several non-c99 features,
and in additional involves arbitrary pointer arithmetic which is not MIS-
RA C friendly.
This patch introduces struct per_cpu_region which holds all the per_cpu
variables. Allocation of per_cpu data regions and access to per_cpu vari-
ables are greatly simplified, at the cost of making all per_cpu varaibl-
es accessible in files.
Signed-off-by: Huihuang Shi <huihuang.shi@intel.com>
