Lifecycle Manager will be refined in v2.7, this patch will
refine enable s5 document to align with the latest code.
v1-->v2:
Remove the prompt from all instructions in this
document.
Tracked-On: #6652
Signed-off-by: Xiangyang Wu <xiangyang.wu@intel.com>
This patch is to eliminate kernel error msgs:
'ACPI Error: AE_NOT_FOUND, Evaluating _PSS'
This is caused by missing of _PSS table in guest ACPI. It would
happen when pstate is not injected to the guest.
Kernel ACPI pstate driver first probes
_PPC(performance capabilites) and _PCT(performance control)
in ACPI. If they exist, then it loads the _PSS(performance state).
If _PPC/_PCT are presented while _PSS is missing, it prints
the error msg.
In acrn-dm, _PPC/_PCT are hard-coded to all vCPUs, while _PSS
are constructed with the pCPUs' pstate data. This is base on
assumption that all VMs can have pstate.
Now the pstate is given to VM only when the VM is not sharing
any CPU(and no RTVM is setup in the scenario).
When the VM doesn't have pstate, the hypercall will return px_cnt=0,
and the _PSS is not constructed. In this case, _PPC/PCT should not
be injected, too.
Tracked-On: #6848
Signed-off-by: Zhou, Wu <wu.zhou@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
Acked-by: Eddie Dong <eddie.dong@Intel.com>
Avoid failing hypercalls by returning 0 for empty PX and CX tables on
HC_PM_GET_CPU_STATE/PMCMD_GET_PX_CNT and
HC_PM_GET_CPU_STATE/PMCMD_GET_CX_CNT.
Tracked-On: #6848
Signed-off-by: Helmut Buchsbaum <helmut.buchsbaum@opensource.tttech-industrial.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
Acked-by: Eddie Dong <eddie.dong@Intel.com>
Secure interrupt (interrupt belongs to TEE) comes
when TEE vcpu is running, the interrupt will be
injected to TEE directly. But when REE vcpu is running
at that time, we need to switch to TEE for handling.
Non-Secure interrupt (interrupt belongs to REE) comes
when REE vcpu is running, the interrupt will be injected
to REE directly. But when TEE vcpu is running at that time,
we need to inject a predefined vector to TEE for notification
and continue to switch back to TEE for running.
To sum up, when secure interrupt comes, switch to TEE
immediately regardless of whether REE is running or not;
when non-Secure interrupt comes and TEE is running,
just notify the TEE and keep it running, TEE will switch
to REE on its own initiative after completing its work.
Tracked-On: projectacrn#6571
Signed-off-by: Jie Deng <jie.deng@intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
Acked-by: Eddie Dong <eddie.dong@Intel.com>
This patch implements the following x86_tee hypercalls,
- HC_TEE_VCPU_BOOT_DONE
- HC_SWITCH_EE
Tracked-On: #6571
Signed-off-by: Jie Deng <jie.deng@intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
Acked-by: Eddie Dong <eddie.dong@Intel.com>
This patch adds the x86_tee hypercall interfaces.
- HC_TEE_VCPU_BOOT_DONE
This hypercall is used to notify the hypervisor that the TEE VCPU Boot
is done, so that we can sleep the corresponding TEE VCPU. REE will be
started at the last time this hypercall is called by TEE.
- HC_SWITCH_EE
For REE VM, it uses this hypercall to request TEE service.
For TEE VM, it uses this hypercall to switch back to REE
when it completes the REE service.
Tracked-On: #6571
Signed-off-by: Jie Deng <jie.deng@intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
Acked-by: Eddie Dong <eddie.dong@Intel.com>
TEE is a secure VM which has its own partitioned resources while
REE is a normal VM which owns the rest of platform resources.
The TEE, as a secure world, it can see the memory of the REE
VM, also known as normal world, but not the other way around.
But please note, TEE and REE can only see their own devices.
So this patch does the following things:
1. go through physical e820 table, to ept add all system memory entries.
2. remove hv owned memory.
Tracked-On: #6571
Signed-off-by: Jie Deng <jie.deng@intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
Acked-by: Eddie Dong <eddie.dong@Intel.com>
Given an e820, this API creates an identical memmap for specified
e820 memory type, EPT memory cache type and access right.
Tracked-On: #6571
Signed-off-by: Jie Deng <jie.deng@intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
Acked-by: Eddie Dong <eddie.dong@Intel.com>
Add a configuration to support companion VM.
Tracked-On: #6571
Signed-off-by: Jie Deng <jie.deng@intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
Add two VM flags for x86_tee. GUEST_FLAG_TEE for TEE VM,
GUEST_FLAG_REE for normal rich VM.
Tracked-On: #6571
Signed-off-by: Jie Deng <jie.deng@intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
The HV will be built failed with below compiler message:
common/efi_mmap.c: In function ‘init_efi_mmap_entries’:
common/efi_mmap.c:41:11: error: unused variable ‘efi_memdesc_nr’
[-Werror=unused-variable]
uint32_t efi_memdesc_nr = uefi_info->memmap_size / uefi_info->memdesc_size;
^~~~~~~~~~~~~~
cc1: all warnings being treated as errors
The root cause is ASSERT() api is for DEBUG only so efi_memdesc_nr is not used
in RELEASE code.
The patch fix this issue by removing efi_memdesc_nr declaration;
Tracked-On: #6834
Signed-off-by: Victor Sun <victor.sun@intel.com>
Add assert for below invalid scenario:
1. Two or more pre-launched RTVM
2. One pre-launched RTVM and one or more post-launched RTVM
Tracked-On: #6685
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
1. remove CONFIG_KATA_VM, CONFIG_MAX_KATA_VM_NUM and KATA_VM
related code.
2. remove KATA_VM in scenario xml files.
3. remove KATA vm type in UI.
4. remove UUID DB.
5. remove uuid in the launch script generation logic.
6. use vmname to identify a vm. (eg: <name>ACRN_SOS_VM</name>)
add the check logic to ensure vm name is a must-set item, not duplicated,
and the string length is [1-15] and the whitespace is not allowed.
7. enlarge the max VM num to 32.
Tracked-On: #6685
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
Since the UUID is not a *must* set parameter for the standard post-launched
VM which doesn't depend on any static VM configuration. We can remove
the KATA related code from hypervisor as it belongs to such VM type.
v2-->v3:
separate the struce acrn_platform_info change of devicemodel
v1-->v2:
update the subject and commit msg
Tracked-On:#6685
Signed-off-by: Chenli Wei <chenli.wei@intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
Since the UUID is not a *must* set parameter for the standard post-launched
VM which doesn't depend on any static VM configuration. We can remove
the KATA related code from hypervisor as it belongs to such VM type.
v2-->v3:
separate the struce acrn_platform_info change of devicemodel
v1-->v2:
update the subject and commit msg
Tracked-On:#6685
Signed-off-by: Chenli Wei <chenli.wei@intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
replace MAX_VMNAME_LEN with MAX_VM_NAME_LEN
to keep sync with HV and devicemodel
Tracked-On: #6685
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
The UUID has several usages before:
1, For HV to identify the static VM configuration of post-launched VM.
2, Seed virtualization.
3, Slightly prevent launching malicous VM from SOS as lack of secure
boot.
The UUID is confused to user, user don't understand what it is. And user
don't know where to get/apply the UUID. The worst experience is user
can't launch any VMs w/o re-compile the hv. Everything needs to be
static decided in building phase.
Now we decide to remove UUID and split each usage. For 1st usage, use
vmname as the identifier of static VM configuration. For 2nd one, we
will use --vseed as the new parameter. For 3rd one, will pretect by
SOS's dm-verity.
This patch will remove the UUID parameter and support 1st&3rd usages
from DM part. For 2nd usage, another patch will be submitted later.
Tracked-On: #6685
Signed-off-by: Yuanyuan Zhao <yuanyuan.zhao@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
With current arch design the UUID is used to identify ACRN VMs,
all VM configurations must be deployed with given UUIDs at build time.
For post-launched VMs, end user must use UUID as acrn-dm parameter
to launch specified user VM. This is not friendly for end users
that they have to look up the pre-configured UUID before launching VM,
and then can only launch the VM which its UUID in the pre-configured UUID
list,otherwise the launch will fail.Another side, VM name is much straight
forward for end user to identify VMs, whereas the VM name defined
in launch script has not been passed to hypervisor VM configuration
so it is not consistent with the VM name when user list VM
in hypervisor shell, this would confuse user a lot.
This patch will resolve these issues by removing UUID as VM identifier
and use VM name instead:
1. Hypervisor will check the VM name duplication during VM creation time
to make sure the VM name is unique.
2. If the VM name passed from acrn-dm matches one of pre-configured
VM configurations, the corresponding VM will be launched,
we call it static configured VM.
If there is no matching found, hypervisor will try to allocate one
unused VM configuration slot for this VM with given VM name and get it
run if VM number does not reach CONFIG_MAX_VM_NUM,
we will call it dynamic configured VM.
3. For dynamic configured VMs, we need a guest flag to identify them
because the VM configuration need to be destroyed
when it is shutdown or creation failed.
v7->v8:
-- rename is_static_vm_configured to is_static_configured_vm
-- only set DM owned guest_flags in hcall_create_vm
-- add check dynamic flag in get_unused_vmid
v6->v7:
-- refine get_vmid_by_name, return the first matching vm_id
-- the GUEST_FLAG_STATIC_VM is added to identify the static or
dynamic VM, the offline tool will set this flag for
all the pre-defined VMs.
-- only clear name field for dynamic VM instead of clear entire
vm_config
Tracked-On: #6685
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Reviewed-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Victor Sun<victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Rename function name to get-common-clos-count and refine the
calculation. Some platforms have odd clos counts. Using "floor" to get
integer numbers for macros.
Tracked-On: #6755
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
1. ensure cpu affinity in launch xml is subset of its scenario settings.
2. cpu_affinity is a must have parameter for acrn_dm, if the user did not provide cpu affinity in launch xml, load it from scenario settings.
Tracked-On: #6724
Signed-off-by: Weiyi Feng <weiyix.feng@intel.com>
when we add two or more virtio block devices and rename them for a VM
in launch xml files, then generate launch scripts through the UI.
After ensuring the devices names are different, we repeat these operations
continuously. Finally we will get the duplicate PT_SLOT value for
different virtio block devices in a launch script. This is wrong.
After user click the "Generate Launch Script" button to generate the
launch scripts every time, we will reset PT_SLOT variate to fix the issue.
Tracked-On: #6767
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
The CONFIG_MAX_IR_ENTRIES and CONFIG_MAX_PT_IRQ_ENTRIES are separate
configuration items, and they can be configured through configuration tool
When the number of PT irq entries are more than IR entries, then some
passthrough devices' irqs may failed to be protected by interrupt
remapping or automatically injected by post-interrupt mechanism.
And it waste memory if the CONFIG_MAX_IR_ENTRIES is larger.
This patch replace the CONFIG_MAX_IR_ENTRIES to MAX_IR_ENTRIES and
enforce it align to CONFIG_PT_IRQ_ENTRIES and round up to > 2^n as the
IRTA_REG spec.This way can enforce all PT irqs works with IR or PI
mechanism.
Tracked-On: #6745
Signed-off-by: Chenli Wei <chenli.wei@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
- Replace SOS or Service OS with Service VM
- Replace UOS or User OS with User VM
- Clean up some of the grammar
Signed-off-by: Amy Reyes <amy.reyes@intel.com>
Amy Reyes