Need to call hv_access_memory_region_update() explicitly for DRHD
registers to correctly grant access rights for hypervisor.
Currently, other hv_access_memory_region_update() calls happen to
cover the DRHD addresses for currently supported platforms.
Tracked-On: #3194
Signed-off-by: Zide Chen <zide.chen@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
The memory size and IOMMU number are refined to meet with ICL board requirement.
Otherwise the ACRN hypervisor can't be booted on the new ICL board.
ICL(the abbreviation of Ice Lake) is the next generation platform based on 10nm.
CPU is based on Sunny Cove microarchitecture and GPU is based on gen11.
The new board is named as icl-rvp.
Tracked-On: #3216
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Binbin Wu <binbin.wu@intel.com>
Currently vlapic id of SOS VM is virtualized, it is indexed by vcpuid in
physical APIC id sequence, but CPUID 0BH leaf still report physical
APIC ID. In SDC/INDUSTRY scenario they are identical mapping so no issue
occured. In hybrid mode this would be a problem because vAPIC ID might
be different with pAPIC ID. We need to make the APIC ID which returned from
CPUID consistent with the one returned from LAPIC register.
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Hybrid scenario will run 3 VMs: one pre-launched VM, one pre-launched SOS VM
and one post-launched Standard VM.
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
to support grub multiboot for nuc7i7bnh, we should put hv ram start
at a suitable address as SOS bzImage may need use 0x1000000
Tracked-On: #3214
Signed-off-by: Jason Chen CJ <jason.cj.chen@intel.com>
Reviewed-by: Victor Sun <victor.sun@intel.com>
The vcpu num could be calculated based on pcpu_bitmap when prepare_vcpu()
is done, so remove this redundant configuration item;
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
vm_apicid2vcpu_id() might return invalid vcpu id, when this happens
we should return -1 in vlapic_x2apic_pt_icr_access();
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
The print message of source and target vcpu id is incorrect, fix it.
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Some OS like Zephyr need to run at 0x100000, so modify the ve820 table
accordingly;
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Previously multiboot mods[0] is designed for kernel module for all
pre-launched VMs including SOS VM, and mods[0].mm_string is used
to store kernel cmdline. This design could not satisfy the requirement
of hybrid mode scenarios that each VM might use their own kernel image
also ramdisk image. To resolve this problem, we will use a tag in
mods mm_string field to specify the module type. If the tag could
be matched with os_config of VM configurations, the corresponding
module would be loaded;
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
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>
Use a misc_cfg.h in each board configs folder so that VM configurations
could include board specific MACROs;
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Add vuart_deinit to vm shutdown so that the vuart resource can be
reset, and when the Guest VM restart, it could have right state.
Tracked-On: #2987
Signed-off-by: Conghui Chen <conghui.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Currently when get_rsdp is called, the EFI depriv_boot env is not initialized.
In such case it will fallback to the legacy mechanism of ACPI table.
If the ACPI table based on legacy mechanism is not found, it will fail to get
the ACPI table and then the system will hang.
On the old platform it still can parse the ACPI table from legacy mechanism.
In fact when EFI RSDP exists, the EFI RSDP is preferred instead of legacy ACPI
RSDP.
In order to avoid multiple calling of depriv_init_boot, the init_boot_operations
is renamed and called after X2apic is enabled(early_init_lapic).
Tracked-On: #3184
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
According to Chap 23.8 RESTRICTIONS ON VMX OPERATION, Vol 3, SDM:
"Any attempt to set one of these bits to an unsupported value while in VMX
operation (including VMX root operation) using any of the CLTS, LMSW, or
MOV CR instructions causes a general-protection exception."
So we don't need to trap them out then inject the GP in hypervisor.
Tracked-On: #2561
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
FuSa requires setting CR4.SMAP/SMEP/PKE will invalidate the TLB. However,
setting CR4.SMAP will invalidate the TLB on native while not in non-root mode.
To make sure this, we will trap CR4.SMAP/SMEP/PKE setting to invalidate the TLB
in root mode.
Tracked-On: #2561
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
Since the vapic_id is from VM, need to check for pre-condition before passing
vcpu_id to vcpu_from_vid. This is in the path of LAPIC passthrough ICR
access
Tracked-On: #3170
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
Present SGX related MSRs to guest if SGX is supported.
- MSR_IA32_SGXLEPUBKEYHASH0 ~ MSR_IA32_SGXLEPUBKEYHASH3:
SGX Launch Control is not supported, so these MSRs are read only.
- MSR_IA32_SGX_SVN_STATUS:
read only
- MSR_IA32_FEATURE_CONTROL:
If SGX is support in VM, opt-in SGX in this MSR.
- MSR_SGXOWNEREPOCH0 ~ MSR_SGXOWNEREPOCH1:
The two MSRs' scope is package level, not allow guest to change them.
Still leave them in unsupported_msrs array.
Tracked-On: #3179
Signed-off-by: Binbin Wu <binbin.wu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
If sgx is supported in guest, present SGX capabilities to guest.
There will be only one EPC section presented to guest, even if EPC
memory for a guest is from muiltiple physcial EPC sections.
Tracked-On: #3179
Signed-off-by: Binbin Wu <binbin.wu@intel.com>
Reviewed-by: Yan, Like <like.yan@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Build EPT entries for SGX EPC resource for VMs.
- SOS: EPC resrouce will be removed from EPT of SOS, don't support SGX virtualization for SOS.
- Non-SOS: build ept mapping for EPC resource for guest.
Guest base address and size is specified in vm configuration.
Tracked-On: #3179
Signed-off-by: Binbin Wu <binbin.wu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Add EPC information in vm configuration structure.
EPC information contains the EPC base and size allocated to a VM.
Tracked-On: #3179
Signed-off-by: Binbin Wu <binbin.wu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Get the platform EPC resource and partiton the EPC resource for VMs
according to VM configurations.
Don't support sgx capability in SOS VM.
init_sgx is called during platform bsp initialization.
If init_sgx() fails, consider it as configuration error, panic the system.
init_sgx() fails if one of the following happens when at least one VM requests
EPC resource if no enough EPC resource for all VMs.
No further check if sgx is not supported by platform or not opted-in in BIOS,
just disable SGX support for VMs.
Tracked-On: #3179
Signed-off-by: Binbin Wu <binbin.wu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
When we call reset_vm() function to reset vm, the vm state
should be reset to VM_CREATED as well.
Tracked-On: #3182
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Fix a logic error when set iommu page walk coherent.
Tracked-On: #3160
Signed-off-by: Binbin Wu <binbin.wu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Define a static mptable array and each VM could index its vmptable by
vm id, then mptable is not needed in vm configurations;
Tracked-On: #2291
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
In current code, vpci do the pci enumartion and add pci devices to the
context table of iommu.
Need to enable iommu DMA address translation later than vpci init.
Otherwise, in UEFI platform, there will be a shot time that address translation
is enabled, but the context table is not setup.
For the devices active in UEFI environment will have problem on address translation.
Tracked-On: #3160
Signed-off-by: Binbin Wu <binbin.wu@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
At the time the guest is switching to X2APIC mode, different VCPUs in the
same VM could expect the setting of the per VM msr_bitmap differently,
which could cause problems.
Considering different approaches to address this issue:
1) only guest BSP can update msr_bitmap when switching to X2APIC.
2) carefully re-write the update_msr_bitmap_x2apic_xxx() functions to
make sure any bit in the bitmap won't be toggled by the VCPUs.
3) make msr_bitmap as per VCPU.
We chose option 3) because it's simple and clean, though it takes more
memory than other options.
BTW, need to remove const modifier from update_msr_bitmap_x2apic_xxx()
functions to get it compiled.
Tracked-On: #3166
Signed-off-by: Zide Chen <zide.chen@intel.com>
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
APL NUC would expose different MWAIT support status with different
BIOS configuration, then the acpi idle driver would have problem if
we provide MWAIT Cx data only. Now we will enforce guest enter port
IO Cx even BIOS expose support of MWAIT.
Given all Broxton family share same port IO Cx data, we use a unified
struct cpu_cx_data cx_bxt[] for all Broxton SoCs;
Tracked-On: #3158
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
The previous function just check the pstate target value in PERF_CTL msr
by indexing px data control value which comes from ACPI table, this would
bring a bug in the case that guest is running intel_pstate_driver:
the turbo pstate target value from intel_pstate driver is in a range
instead of fixed value in ACPI _PSS table, thus the turbo px request would
be rejected. This patch fixed this issue.
Tracked-On: #3158
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
Add Px/Cx data of Intel Core(TM) i7-8650U CPU which used by NUC7i7DNH to
enable guest controlled CPU power states;
Tracked-On: #3158
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
filter out prelaunched vm memory from e820 table
and unmap prelaunched vm memory from ept table
before boot service OS
Tracked-On: #3148
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
- add the GUEST_FLAG_HIGHEST_SEVERITY flag to indicate that the guest has
privilege to reboot the host system.
- this flag is statically assigned to guest(s) in vm_configurations.c in
different scenarios.
- implement reset_host() function to reset the host. First try the ACPI
reset register if available, then try the 0xcf9 PIO.
Tracked-On: #3145
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
Signed-off-by: Zide Chen <zide.chen@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
And make other related changes accordingly:
Remove pci_pdev_enumeration_cb define
Create init_vdevs() to iterate through the pdev list and create vdev for each pdev
Export num_pci_pdev and pci_pdev_array as globals in header file
Minor cosmetic fix:
Remove trailing whitespace
Tracked-On: #3022
Signed-off-by: dongshen <dongsheng.x.zhang@intel.com>
Reviewed-by: Eddie Dong <eddie.dong@intel.com>
ACRN supports LAPIC emulation for guests using x86 APICv. When guest OS/BIOS
switches from xAPIC to x2APIC mode of operation, ACRN also supports switching
froom LAPIC emulation to LAPIC passthrough to guest. User/developer needs to
configure GUEST_FLAG_LAPIC_PASSTHROUGH for guest_flags in the corresponding
VM's config for ACRN to enable LAPIC passthrough.
This patch does the following
1)Fixes a bug in the abovementioned feature. For a guest that is
configured with GUEST_FLAG_LAPIC_PASSTHROUGH, during the time period guest is
using xAPIC mode of LAPIC, virtual interrupts are not delivered. This can be
manifested as guest hang when it does not receive virtual timer interrupts.
2)ACRN exposes physical topology via CPUID leaf 0xb to LAPIC PT VMs. This patch
removes that condition and exposes virtual topology via CPUID leaf 0xb.
Tracked-On: #3136
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
Reviewed-by: Eddie Dong <eddie.dong@intel.com>
the pcpu just write its own vmcs, not need spinlock.
and the arch.lock not used other places, remove it too.
Tracked-On: #3130
Signed-off-by: Minggui Cao <minggui.cao@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
add spinlock to dmar_enable_qi & dmar_disable_qi to protect
struct dmar_unit variables; keep consistent with other same
level functions.
Tracked-On: #3130
Signed-off-by: Minggui Cao <minggui.cao@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
now only SOS need decide boot with de-privilege or direct boot mode, while
for other pre-launched VMs, they should use direct boot mode.
this patch merge boot/guest/direct_boot_info.c &
boot/guest/deprivilege_boot_info.c into boot/guest/vboot_info.c,
and change init_direct_vboot_info() function name to init_general_vm_boot_info().
in init_vm_boot_info(), depend on get_sos_boot_mode(), SOS may choose to init
vm boot info by setting the vm_sw_loader to deprivilege specific one; for SOS
using DIRECT_BOOT_MODE and all other VMS, they will use general_sw_loader as
vm_sw_loader and go through init_general_vm_boot_info() for virtual boot vm
info filling.
this patch also move spurious handler initilization for de-privilege mode from
boot/guest/deprivilege_boot.c to boot/guest/vboot_info.c, and just set it in
deprivilege sw_loader before irq enabling.
Changes to be committed:
modified: Makefile
modified: arch/x86/guest/vm.c
modified: boot/guest/deprivilege_boot.c
deleted: boot/guest/deprivilege_boot_info.c
modified: boot/guest/direct_boot.c
renamed: boot/guest/direct_boot_info.c -> boot/guest/vboot_info.c
modified: boot/guest/vboot_wrapper.c
modified: boot/include/guest/deprivilege_boot.h
modified: boot/include/guest/direct_boot.h
modified: boot/include/guest/vboot.h
new file: boot/include/guest/vboot_info.h
modified: common/vm_load.c
modified: include/arch/x86/guest/vm.h
Tracked-On: #1842
Signed-off-by: Jason Chen CJ <jason.cj.chen@intel.com>
Handle the PIO reset register that is defined in host ACPI:
Parse host FADT table to get the host reset register info, and emulate
it for Service OS:
- return all '1' for guest reads because the read behavior is not defined
in ACPI.
- ignore guest writes with the reset value to stop it from resetting host;
if guest writes other values, passthru it to hardware in case the reset
register supports other functionalities.
Tracked-On: #2700
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
Signed-off-by: Zide Chen <zide.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
This patch implements triple fault vmexit handler and base on VM types:
- post-launched VMs: shutdown_target_vm() injects S5 PIO write to request
DM to shut down the target VM.
- pre-launched VMs: shut down the guest.
- SOS: similarly, but shut down all the non real-time post-launched VMs that
depend to SOS before shutting down SOS.
Tracked-On: #2700
Signed-off-by: Zide Chen <zide.chen@intel.com>
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
- post-launched RTVM: intercept both PIO ports so that hypervisor has a
chance to set VM_POWERING_OFF flag.
- all other type of VMs: deny these 2 ports from guest access so that
guests are not able to reset host.
Tracked-On: #2700
Signed-off-by: Zide Chen <zide.chen@intel.com>
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
For pre-launched VMs and SOS, VM shutdown should not be executed in the
current VM context.
- implement NEED_SHUTDOWN_VM request so that the BSP of the target VM can shut
down the guest in idle thread.
- implement shutdown_vm_from_idle() to shut down target VM.
Tracked-On: #2700
Signed-off-by: Zide Chen <zide.chen@intel.com>
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
1) According SDM Vol 3, Chap 29.1.2, Any VM exit caused by TPR virtualization
is trap-like: the instruction causing TPR virtualization completes before the VM
exit occurs (for example, the value of CS:RIP saved in the guest-state area of
the VMCS references the next instruction). So we need to retain the RIP.
2) The previous implement only consides the situation the guest will reduce the
TPR. However, the guest will increase it. So we need to update the PPR before we
find a deliverable interrupt. For examples: a) if the guest increase the TPR before
a irq windows vmexit, we need to update the PPR when check whether there has a pending
delivery interrupt or not; b) if the guest increase the TPR, then an external irq raised,
we need to update the PPR when check whether there has a deliverable interrupt to inject
to guest.
Tracked-On: #1842
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
Reviewed-by: Yu Wang <yu1.wang@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
For prelaunched VM, Service OS and postlaunched RT VM, we only need the vRTC
provides backed-up date, so we could use the simple vRTC which implemented
in hypervisor. For postlaunched VM (which is not a RT VM), we needs the device
module to emulate the vRTC for it.
Tracked-On: #1842
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
Reviewed-by: Yu Wang <yu1.wang@intel.com>
