Get the max number with integer list to instead string 'number'.
Tracked-On: #5199
Signed-off-by: Shuang Zheng <shuang.zheng@intel.com>
Acked-by: Victor Sun <victor.sun@intel.com>
realpath function would be got null while the directory or file is
not exist, modify the function abspath to instead realpath.
Tracked-On: #5146
Signed-off-by: Wei Liu <weix.w.liu@intel.com>
This patch will move the VM configuration check to pre-build stage,
a test program will do the check for pre-defined VM configuration
data before making hypervisor binary. If test failed, the make
process will be aborted. So once the hypervisor binary is built
successfully or start to run, it means the VM configuration has
been sanitized.
The patch did not add any new VM configuration check function,
it just port the original sanitize_vm_config() function from cpu.c
to static_checks.c with below change:
1. remove runtime rdt detection for clos check;
2. replace pr_err() from logmsg.h with printf() from stdio.h;
3. replace runtime call get_pcpu_nums() in ALL_CPUS_MASK macro
with static defined MAX_PCPU_NUM;
4. remove cpu_affinity check since pre-launched VM might share
pcpu with SOS VM;
The BOARD/SCENARIO parameter check and configuration folder check is
also moved to prebuild Makefile.
Tracked-On: #5077
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Remove function of sanitize_vm_config() since the processing of sanitizing
will be moved to pre-build process.
When hypervisor has booted, we assume all VM configurations is sanitized;
Tracked-On: #5077
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Previously we have complicated check mechanism on platform_acpi_info.h which
is supposed to be generated by acrn-config tool, but given the reality that
all configurations should be generated by acrn-config before build acrn
hypervisor, this check is not needed anymore.
Tracked-On: #5077
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
CPU sharing between pre-launch VMs and SOS, post-launch VMs were
forbidden.
Remove the limitation.
Tracked-On: #5153
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Add cpu_affinity setup for SOS VM. Cpu affinity must be set in
scenario XML, except if no pre-launched VM on the scenario and
all pCPUs will be assigned to SOS VM in that case;
Tracked-On: #5077
Signed-off-by: Wei Liu <weix.w.liu@intel.com>
Previously the CPU affinity of SOS VM is initialized at runtime during
sanitize_vm_config() stage, follow the policy that all physical CPUs
except ocuppied by Pre-launched VMs are all belong to SOS_VM. Now change
the process that SOS CPU affinity should be initialized at build time
and has the assumption that its validity is guarenteed before runtime.
Tracked-On: #5077
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Currently, there are 2 vuarts for each VM, vuart 0 is for console, vuart
1 is for communication.
As the requirement for communication between more VMs, add 2 additional
vuarts for each VM.
Tracked-On: #5138
Signed-off-by: Conghui Chen <conghui.chen@intel.com>
2abbb99f6a ("hv: make thread status more accurate") introduced a
transition stage, marked as var be_blocking, between RUNNING->BLOCKED
of thread status. wake_thread() does not work in this transition stage
because it only checks thread->status.
Need to check thread->be_blocking as well in wake_thread(). When
wake_thread() happens in the transition stage, the previous sleep
operation rolled back.
Tracked-On: #5122
Fixes: 2abbb99f6a ("hv: make thread status more accurate")
Signed-off-by: Conghui Chen <conghui.chen@intel.com>
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
The SDC scenario configurations will not be validated so remove it from
build makefile;
Tracked-On: #5077
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
As we only set BLOCKED status in context switch_out, which means, only
running thread can be changed to BLOCKED, but runnable thread can not.
This lead to the deadloop in sleep_thread_sync.
To solve the problem, in sleep_thread, we set the status to BLOCKED
directly when the original thread status is RUNNABLE.
Tracked-On: #5115
Signed-off-by: Conghui Chen <conghui.chen@intel.com>
arch_vm member of struct acrn_vm is page aligned. memset used in create_vm
subtracts only 8 bytes, sizeof(spinlock_t) from the size of acrn_vm and uses
the vm->arch_vm as the destination address. To do it right, it should subtract
4096 bytes. This would result in writing memory beyond the acrn_vm struct.
This patch fixes the issue by using offsetof compiler macro and subtracts the
right amount of size corresponding to the beginning of arch_vm member in
struct acrn_vm.
Tracked-On: #5107
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
The folders for config xmls and scenario setting source code are moved
to misc/vm_configs/xmls and misc/vm_configs/board, misc/vm_configs/scenario,
so this patch is to update config path for these folders.
Tracked-On: #5077
Signed-off-by: Shuang Zheng <shuang.zheng@intel.com>
Add xmls/samples folders under misc/vm_configs, and make soft link for
them.
Tracked-On: #5077
Signed-off-by: Wei Liu <weix.w.liu@intel.com>
Acked-by: Victor Sun <victor.sun@intel.com>
Add hybrid_rt source code for whl-ipc-i5/i7.
Tracked-On: #5081
Signed-off-by: Wei Liu <weix.w.liu@intel.com>
Acked-by: Victor Sun <victor.sun@intel.com>
1.Refine cpu affinity in hybrid rt xmls for whl-ipc-i5/7
2.Refine guest flag for hybrid rt xmls for whl-ipc-i5/7
Tracked-On: #5081
Signed-off-by: Wei Liu <weix.w.liu@intel.com>
Acked-by: Victor Sun <victor.sun@intel.com>
Add support to generate passthru TPM information for whl-ipc-i5/i7.
Tracked-On: #5077
Signed-off-by: Wei Liu <weix.w.liu@intel.com>
Acked-by: Victor Sun <victor.sun@intel.com>
There is some macro defined in misc_cfg.h while CAT/MBA enabled.
include the missing header to solve build issue.
Tracked-On: #5092
Signed-off-by: Wei Liu <weix.w.liu@intel.com>
Acked-by: Victor Sun <victor.sun@intel.com>
When VM read pre-sriov header in ECAP of ptdev, only emulate the
reading if SRIOV is hidden.
Write to pre-sriov header is ignored so no need to fix writting.
Tracked-On: #5085
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
Now the hypervisor configuration source code layout is changed, so acrn-config
need to change accordingly to make sure XML based configuration build success;
Tracked-On: #5077
Signed-off-by: Wei Liu <weix.w.liu@intel.com>
Acked-by: Victor Sun <victor.sun@intel.com>
The old layout configuration source which located in:
hypervisor/arch/x86/configs/ is abandoned, remove it;
Tracked-On: #5077
Signed-off-by: Victor Sun <victor.sun@intel.com>
Add acrn-config tool formated nuc7i7dnb configurations code in misc/vm_configs/
folder with new layout;
Tracked-On: #5077
Signed-off-by: Victor Sun <victor.sun@intel.com>
The make command is same as old configs layout:
under acrn-hypervisor folder:
make hypervisor BOARD=xxx SCENARIO=xxx [TARGET_DIR]=xxx [RELEASE=x]
under hypervisor folder:
make BOARD=xxx SCENARIO=xxx [TARGET_DIR]=xxx [RELEASE=x]
if BOARD/SCENARIO parameter is not specified, the default will be:
BOARD=nuc7i7dnb SCENARIO=industry
Tracked-On: #5077
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
There are 3 kinds of configurations in ACRN hypervisor source code: hypervisor
overall setting, per-board setting and scenario specific per-VM setting.
Currently Kconfig act as hypervisor overall setting and its souce is located at
"hypervisor/arch/x86/configs/$(BOARD).config"; Per-board configs are located at
"hypervisor/arch/x86/configs/$(BOARD)" folder; scenario specific per-VM configs
are located at "hypervisor/scenarios/$(SCENARIO)" folder.
This layout brings issues that board configs and VM configs are coupled tightly.
The board specific Kconfig file and misc_cfg.h are shared by all scenarios, and
scenario specific pci_dev.c is shared by all boards. So the user have no way to
build hypervisor binary for different scenario on different board with one
source code repo.
The patch will setup a new VM configurations layout as below:
misc/vm_configs
├── boards --> folder of supported boards
│ ├── <board_1> --> scenario-irrelevant board configs
│ │ ├── board.c --> C file of board configs
│ │ ├── board_info.h --> H file of board info
│ │ ├── pci_devices.h --> pBDF of PCI devices
│ │ └── platform_acpi_info.h --> native ACPI info
│ ├── <board_2>
│ ├── <board_3>
│ └── <board...>
└── scenarios --> folder of supported scenarios
├── <scenario_1> --> scenario specific VM configs
│ ├── <board_1> --> board specific VM configs for <scenario_1>
│ │ ├── <board_1>.config --> Kconfig for specific scenario on specific board
│ │ ├── misc_cfg.h --> H file of board specific VM configs
│ │ ├── pci_dev.c --> board specific VM pci devices list
│ │ └── vbar_base.h --> vBAR base info of VM PT pci devices
│ ├── <board_2>
│ ├── <board_3>
│ ├── <board...>
│ ├── vm_configurations.c --> C file of scenario specific VM configs
│ └── vm_configurations.h --> H file of scenario specific VM configs
├── <scenario_2>
├── <scenario_3>
└── <scenario...>
The new layout would decouple board configs and VM configs completely:
The boards folder stores kinds of supported boards info, each board folder
stores scenario-irrelevant board configs only, which could be totally got from
a physical platform and works for all scenarios;
The scenarios folder stores VM configs of kinds of working scenario. In each
scenario folder, besides the generic scenario specific VM configs, the board
specific VM configs would be put in a embedded board folder.
In new layout, all configs files will be removed out of hypervisor folder and
moved to a separate folder. This would make hypervisor LoC calculation more
precisely with below fomula:
typical LoC = Loc(hypervisor) + Loc(one vm_configs)
which
Loc(one vm_configs) = Loc(misc/vm_configs/boards/<board>)
+ LoC(misc/vm_configs/scenarios/<scenario>/<board>)
+ Loc(misc/vm_configs/scenarios/<scenario>/vm_configurations.c
+ Loc(misc/vm_configs/scenarios/<scenario>/vm_configurations.h
Tracked-On: #5077
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Update the draft content about Debian packaging with something more user
friendly and complete.
I removed the version of the release.json included in the doc and
instead just include the release.json file directly.
I added comments about the configuration parameters directly in the
release.json file, using the convention already being used there.
(If we updated the json python package being used to json5, the
release.json file could include comments using // convention and things
would look a bit cleaner.)
Tracked-On: #5022
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
1.Add UUID for Pre-launched RT VM.
2.Add hybrid_rt.xml for whl-ipc-i7/i5 and also add template Pre-Launched
RT sample xml.
3.Refine sanity check for load_kern_addr/entry.
Tracked-On: #5081
Signed-off-by: Wei Liu <weix.w.liu@intel.com>
Acked-by: Victor Sun <victor.sun@intel.com>
Add Null pointer check in reset and stop endpoint command handle
function to avoid Null pointer exception. Fllow xHCI spec 4.6.8 and
4.6.9, for stop and reset endpoint command, when the slot state is
Disabled the error code should be Slot Not Enabled Error, when the
slot have been enabled by an Enable Slot Command the error code should
be Context State Error.
Tracked-On: #5066
Signed-off-by: Long Liu <long.liu@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
Signed-off-by: Long Liu <long.liu@intel.com>
hv: vpci: inject physical PCIEXBAR to SOS vhostbridge in
order to fully emulate a full host bridge following HW spec
The vhostbridge we emulate currently is a "Celeron N3350/
Pentium N4200/Atom E3900 Series Host Bridge", which is of
Appollo Lake SoC, but the emulation is incomplete, and
we need to implement a full vhostbridge following HW spec.
This is a step-by-step process, and in this patch we fixes
the simulation of PCIEXBAR register (0x60) and thus solved
bug #6464.
-------#6464: SOS cannot make use of ECAM---------------
Generally, SOS will check the MMIO Base Addr in ACPI MCFG
table to confirm it is a reserved memory area. There will
be 3 methods to check:
1. Via E820 table
2. Via EFI runtime service
3. To check with the value in PCIEXBAR(0x60) of hostbridge
For SOS, method 2 is not feasible since no EFI runtime service
is available for SOS. And on newer platform like EHL/TGL, its
BIOS somehow doesn't reserve it in native E820, thus SOS will
try use method 3 to verify, so we should inject physical ECAM
to vhostbridge, otherwise all 3 methods will fail, and SOS will
not make use of ECAM, which will results in that SOS cannot use
PCIe Extended Capabilities like SR-IOV.
-------------------------------------------------------
TODO:
1. In the future, we may add one or more virtual hostbridges for CPUs that are incompatible in layout with the current one, according to HW specs
2. Besides PCIEXBAR(0x60), there are also some registers needs to be emulated more precisely rather than be treated as read-only and hard-coded, will be fixed in future patches.
Tracked-On: #5056
Signed-off-by: Qian Wang <qian1.wang@intel.com>
Reviewed-by: Jason Chen <jason.cj.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
hv: vpci: refine init_vhostbridge to be dword-aligned
Refine the hard-coded non-dword-aligned sentences in init_vhostbridge
to be dword-aligned to simplify the initialization operation
Tracked-On: #5056
Signed-off-by: Qian Wang <qian1.wang@intel.com>
Reviewed-by: Jason Chen <jason.cj.chen@intel.com>
Reviewed-by: Li Fei <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
To hide CET feature from guest VM completely, the MSR IA32_MSR_XSS also
need to be intercepted because it comprises CET_U and CET_S feature bits
of xsave/xstors operations. Mask these two bits in IA32_MSR_XSS writing.
With IA32_MSR_XSS interception, member 'xss' of 'struct ext_context' can
be removed because it is duplicated with the MSR store array
'vcpu->arch.guest_msrs[]'.
Tracked-On: #5074
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Return-oriented programming (ROP), and similarly CALL/JMP-oriented
programming (COP/JOP), have been the prevalent attack methodologies for
stealth exploit writers targeting vulnerabilities in programs.
CET (Control-flow Enforcement Technology) provides the following
capabilities to defend against ROP/COP/JOP style control-flow subversion
attacks:
* Shadow stack: Return address protection to defend against ROP.
* Indirect branch tracking: Free branch protection to defend against
COP/JOP
The full support of CET for Linux kernel has not been merged yet. As the
first stage, hide CET from guest VM.
Tracked-On: #5074
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
On WHL platform, we need to pass through TPM to Secure pre-launched VM. In order
to do this, we need to add TPM2 ACPI Table and add TPM DSDT ACPI table to include
the _CRS.
Now we only support the TPM 2.0 device (TPM 1.2 device is not support). Besides,
the TPM must use Start Method 7 (Uses the Command Response Buffer Interface)
to notify the TPM 2.0 device that a command is available for processing.
Tracked-On: #5053
Signed-off-by: Li Fei1 <fei1.li@intel.com>
Using ACPI_TABLE_HEADER MACRO to initial the ACPI Table Header.
Tracked-On: #5053
Signed-off-by: Li Fei1 <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@Intel.com>
Add mmio device pass through support for pre-launched VM.
When we pass through a MMIO device to pre-launched VM, we would remove its
resource from the SOS. Now these resources only include the MMIO regions.
Tracked-On: #5053
Acked-by: Eddie Dong <eddie.dong@intel.com>
Signed-off-by: Li Fei1 <fei1.li@intel.com>
We could add MMIO device pass through by two ways:
a) If the MMIO device only has MMIO regions and no ACPI Table touched, using
"--mmiodev_pt MMIO_regions",
b) If the MMIO device touches ACPI Table, using "--acpidev_pt HID"
Now only support TPM2 MSFT0101 MMIO device pass through through launch script
using "--acpidev_pt MSFT0101". When we want to pass through the TPM2 deivce,
we would not allow to emulate the vTPM2 at the same time. This is becuase
the ACRN-DM emulate the TPM2 as MSFT0101 too. Otherwise, the VM can't boot.
Besides, we could only support one TPM2 device PT and one MMIO device PT.
For TPM2 device PT, the MMIO resources are hard-coded. For the MMIO device PT,
we could pass through the MMIO resources on the cmdline.
ToDo:
1. We may use HID to discover the MMIO regions and ACPI Table instaed of
hard-coded.
2. To identify a MMIO device only by MMIO regions.
3. To allocate virtual MMIO regions in a reserved guest MMIO regions.
Tracked-On: #5053
Signed-off-by: Li Fei1 <fei1.li@intel.com>
Shuang Zheng