Commit Graph

14 Commits

Author SHA1 Message Date
Wei Liu
7147979382 acrn-config: assign PCPU0~3 to post vm by default
Assign PCPU0~3 to post-launched VM. The CPU affinity can be overridden
with the '--cpu_affinity' parameter of acrn-dm.

v1-v2:
  1) add 3 POST_STD_VM and 1 KATA_VM to industry scenario for whl-ipc/nuc7i7dnb.

v2-v3:
  1) remove the MAX_KATA_VM_NUM from scecnro config.
  2) add gvtd args for nuc7/nuc6 board.

Tracked-On: #4641
Signed-off-by: Wei Liu <weix.w.liu@intel.com>
Acked-by: Victor Sun <victor.sun@intel.com>
2020-04-29 15:36:27 +08:00
Zide Chen
467539441b hv: replace vcpu_affinity array with cpu_affinity_bitmap
Currently the vcpu_affinity[] array fixes the vCPU to pCPU mapping.
While the new cpu_affinity_bitmap doesn't explicitly sepcify this
mapping, instead, it implicitly assumes that vCPU0 maps to the pCPU
with lowest pCPU ID, vCPU1 maps to the second lowest pCPU ID, and
so on.

This makes it possible for post-launched VM to run vCPUs on a subset of
these pCPUs only, and not all of them.

acrn-dm may launch post-launched VMs with the current approach: indicate
VM UUID and hypervisor launches all VCPUs from the PCPUs that are masked
in cpu_affinity_bitmap.

Also acrn-dm can choose to launch the VM on a subset of PCPUs that is
defined in cpu_affinity_bitmap. In this way, acrn-dm must specify the
subset of PCPUs in the CREATE_VM hypercall.

Additionally, with this change, a guest's vcpu_num can be easily calculated
from cpu_affinity_bitmap, so don't assign vcpu_num in vm_configuration.c.

Tracked-On: #4616
Signed-off-by: Zide Chen <zide.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2020-04-23 10:59:08 +08:00
Victor Sun
88bed66e5a HV: refine usage of idle=halt in sos cmdline
The parameter of "idle=halt" for SOS cmdline is only needed when cpu sharing
is enabled, otherwise it will impact SOS power.

Tracked-On: #4329

Signed-off-by: Victor Sun <victor.sun@intel.com>
2020-04-22 20:02:03 +08:00
Victor Sun
7f1c4422bb HV: support up to 7 post launched VMs for industry scenario
In industry scenario, hypervisor will support 1 post-launched RT VM
and 1 post-launched kata VM and up to 5 post-launched standard VMs;

Tracked-On: #4661

Signed-off-by: Victor Sun <victor.sun@intel.com>
2020-04-20 23:58:58 +08:00
Victor Sun
d742be2c5c HV: Kconfig: enable CPU sharing by default
The patch enables CPU sharing feature by default, the default scheduler is
set to SCHED_BVT;

Tracked-On: #4661

Signed-off-by: Victor Sun <victor.sun@intel.com>
2020-04-17 15:57:28 +08:00
Victor Sun
7d173917c4 Kconfig: remove MAX_KATA_VM_NUM
CONFIG_MAX_KATA_VM_NUM is a scenario specific configuration, so it is better
to put the MACRO in scenario folder directly, to instead the Kconfig item in
Kconfig file which should work for all scenarios;

Tracked-On: #4616

Signed-off-by: Victor Sun <victor.sun@intel.com>
2020-04-17 15:00:29 +08:00
Victor Sun
4c0965d89e HV: correct ept page array usage
Currently ept_pages_info[] is initialized with first element only that force
VM of id 0 using SOS EPT pages. This is incorrect for logical partition and
hybrid scenario. Considering SOS_RAM_SIZE and UOS_RAM_SIZE are configured
separately, we should use different ept pages accordingly.

So, the PRE_VM_NUM/SOS_VM_NUM and MAX_POST_VM_NUM macros are introduced to
resolve this issue. The macros would be generated by acrn-config tool when
user configure ACRN for their specific scenario.

One more thing, that when UOS_RAM_SIZE is less then 2GB, the EPT address
range should be (4G + PLATFORM_HI_MMIO_SIZE).

Tracked-On: #4458

Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2020-03-12 14:56:34 +08:00
Shuo A Liu
3239cb0e1c hv: Use HLT as the default idle action of service OS
This patch overwrites the idle driver of service OS for industry, sdc,
sdc2 scenarios. HLT will be used as the default idle action.

Tracked-On: #4329
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2020-01-07 11:23:32 +08:00
Kaige Fu
d5c3523d30 hv: Update industry scenarios configuration
This patch makes the following changes:
  - Remove the 4th VM
  - Make the default vcpu num of RTVM as 2

---
  v1 -> v2: Modify CONFIG_MAX_VM_NUM to 3U + KATA

Tracked-On: #3925
Signed-off-by: Yan, Like <like.yan@intel.com>
Signed-off-by: Kaige Fu <kaige.fu@intel.com>
2019-10-25 15:23:16 +08:00
Shuo A Liu
1c526e6d16 hv: use vcpu_affinity[] in vm_config to support vcpu assignment
Add this vcpu_affinity[] for each VM to indicate the assignment policy.
With it, pcpu_bitmap is not needed, so remove it from vm_config.
Instead, vcpu_affinity is a must for each VM.

This patch also add some sanitize check of vcpu_affinity[]. Here are
some rules:
  1) only one bit can be set for each vcpu_affinity of vcpu.
  2) two vcpus in same VM cannot be set with same vcpu_affinity.
  3) vcpu_affinity cannot be set to the pcpu which used by pre-launched VM.

v4: config SDC with CONFIG_MAX_KATA_VM_NUM
v5: config SDC with CONFIG_MAX_PCPU_NUM

Tracked-On: #3663
Signed-off-by: Jason Chen CJ <jason.cj.chen@intel.com>
Signed-off-by: Yu Wang <yu1.wang@intel.com>
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
2019-09-24 11:58:45 +08:00
Victor Sun
5b1852e482 HV: add kata support on sdc scenario
In current design, devicemodel passes VM UUID to create VMs and hypervisor
would check the UUID whether it is matched with the one in VM configurations.

Kata container would maintain few UUIDs to let ACRN launch the VM, so
hypervisor need to add these UUIDs in VM configurations for Kata running.
In the hypercall of hcall_get_platform_info(), hypervisor will report the
maximum Kata container number it will support. The patch will add a Kconfig
to indicate the maximum Kata container number that SOS could support.

In current stage, only one Kata container is supported by SOS on SDC scenario
so add one UUID for Kata container in SDC VM configuration. If we want to
support Kata on other scenarios in the future, we could follow the example
of this patch;

Tracked-On: #3402

Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2019-07-12 16:34:31 +08:00
Victor Sun
d0fa83b2cb HV: move sos bootargs to vm configurations
Previously the bootargs of SOS_VM is stored in a text file and stitched
into multiboot mods[0].string whereas the bootargs of PRE_LAUNCHED_VM is
stored in vm_configurations.c. Given the mods[].string will be used to
store Kernel image signature under hybrid mode, move the bootargs of SOS_VM
to vm configurations also to make it consistent with PRE_LAUNCHED_VM;

Tracked-On: #3214

Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
2019-06-06 09:40:52 +08:00
Yan, Like
31efa2b522 hv: add one more guest VM to the industry scenario
This commmit added one more guest VM to the industry scenario, to
be aligned with the HLD for the industry usage.
With this commit, 4 VMs could be launched at maximum: 1 SOS VM and 3 post-launced VM.

Tracked-On: #3039
Signed-off-by: Yan, Like <like.yan@intel.com>
2019-05-05 16:38:57 +08:00
Yan, Like
624185c3ca hv: add scenario for the industry use case
This scenario is typical for industry usage with 3 VMs: 1 pre-launched SOS VM,
1 post-launched user VM for HMI and 1 post-launched  RT VM for real-time control.

Tracked-On: #3039
Signed-off-by: Yan, Like <like.yan@intel.com>
2019-04-29 17:03:19 +08:00