MISRA-C standard requires the type of result of expression in if/while pattern shall be boolean.
Tracked-On: #861
Signed-off-by: Huihuang Shi <huihuang.shi@intel.com>
There are a lot of works to do between create_vm (HV will mark vm's state
as VM_CREATED at this stage) and vm_run (HV will mark vm's state as VM_STARTED),
like building mptable/acpi table, initializing mevent and vdevs. If there is
something goes wrong between create_vm and vm_run, the devicemodel will jumps
to the deinit process and will try to destroy the vm. For example, if the
vm_init_vdevs failed, the devicemodel will jumps to dev_fail and then destroy
the vm.
For normal vm in above situation, it is fine to destroy vm. And we can create and
start it next time. But for RTVM, we can't destroy the vm as the vm's state is
VM_CREATED. And we can only destroy vm when its state is VM_POWERING_OFF. So, the
vm will stay at VM_CREATED state and we will never have chance to destroy it.
Consequently, we can't create and start the vm next time.
This patch fixes it by allowing to pause and then destroy RTVM when its state is VM_CREATED.
Tracked-On: #3069
Acked-by: Eddie Dong <eddie.dong@intel.com>
Signed-off-by: Kaige Fu <kaige.fu@intel.com>
wbinvd is used to write back all modified cache lines in the processor's
internal cache to main memory and invalidates(flushes) the internal caches.
Using clflushopt instructions to emulate wbinvd to flush each
guest vm memory, if CLFLUSHOPT is not supported, boot will fail.
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Yuan Liu <yuan1.liu@intel.com>
Reviewed-by: Li, Fei1 <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
The has_rt_vm walk through all VMs to check RT VM flag and if
there is no any RT VM, then return false otherwise return true.
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Yuan Liu <yuan1.liu@intel.com>
Reviewed-by: Li, Fei1 <fei1.li@intel.com>
The ept_flush_leaf_page API is used to flush address space
from a ept page entry, user can use it to match walk_ept_mr to
flush VM address space.
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Yuan Liu <yuan1.liu@intel.com>
Reviewed-by: Li, Fei1 <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
The walk_ept_table API is used to walk through EPT table for getting
all of present pages, user can get each page entry and its size
from the walk_ept_table callback.
The get_ept_entry is used to getting EPT pointer of the vm, if current
context of mv is secure world, return secure world EPT pointer, otherwise
return normal world EPT pointer.
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Yuan Liu <yuan1.liu@intel.com>
Reviewed-by: Li, Fei1 <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
flush_address_space is used to flush address space by clflushopt instruction.
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Yuan Liu <yuan1.liu@intel.com>
Reviewed-by: Li, Fei1 <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
CLFLUSHOPT is used to invalidate from every level of the cache hierarchy
in the cache coherence domain the cache line that contains the linear
address specified with memory operand. If that cache line contains
modified date at any level of the cache hierarchy, that data is written
back to memory.
If the platform does not support CLFLUSHOPT instruction, boot will fail.
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Yuan Liu <yuan1.liu@intel.com>
Reviewed-by: Li, Fei1 <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
The current implement doesn't clear which access type we support for
APIC-Access VM Exit:
1) linear access for an instruction fetch
-- APIC-access page is mapped as UC which doesn't support fetch
2) linear access (read or write) during event delivery
-- Which is not happened in normal case except the guest went wrong, such as,
set the IDT table in APIC-access page. In this case, we don't need to support.
3) guest-physical access during event delivery;
guest-physical access for an instruction fetch or during instruction execution
-- Do we plan to support enable APIC in real mode ? I don't think so.
Tracked-On: #1842
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
In hcall_inject_msi, we check vlapic state of SOS by mistake.
If the SOS's vlapic state doesn't equal to target_vm's, the OVMF will
hang when boot up. Instead, we should check the target_vm's
vlapic state.
Tracked-On: #3069
Acked-by: Eddie Dong <eddie.dong@intel.com>
Reviewed-by: Binbin Wu <binbin.wu@intel.com>
Signed-off-by: Kaige Fu <kaige.fu@intel.com>
Rename MSI-X struct, pci_msix, member from tables to table_entries
Tracked-On: #3265
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
support compiling system initialization code
to sys_init_mod.a
Tracked-On: #1842
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
support compiling virtual platform hypercall to vp_hcall_mod.a
Tracked-On: #1842
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
modified: Makefile
support compiling virtual platform trusty to vp_trusty_mod.a
Tracked-On: #1842
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
modified: Makefile
support compiling virtual platform device model layer
to vp_dm_mod.a
Tracked-On: #1842
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
modified: Makefile
support compiling virtual platform base layer to
vp_base_mod.a
Tracked-On: #1842
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
modified: Makefile
support compiling hw management code to hw_mod.a
Tracked-On: #1842
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
modified: Makefile
support compiling boot code to boot_mod.a
Tracked-On: #1842
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
modified: Makefile
HV has been divided into the following layers
according to Jason's modularization documentation
high: 70 -- system initialization
60 -- virtual platform hypercall
50 -- virtual platform trusty
40 -- virtual platform device model
30 -- virtual platform base
20 -- hardware management
10 -- platform boot
low: 00 -- library
this patch is only for library layer,
support compiling library layer to lib_mod.a
Tracked-On: #1842
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
modified: Makefile
This patch introduces check_vm_vlapic_state API instead of is_lapic_pt_enabled
to check if all the vCPUs of a VM are using x2APIC mode and LAPIC
pass-through is enabled on all of them.
When the VM is in VM_VLAPIC_TRANSITION or VM_VLAPIC_DISABLED state,
following conditions apply.
1) For pass-thru MSI interrupts, interrupt source is not programmed.
2) For DM emulated device MSI interrupts, interrupt is not delivered.
3) For IPIs, it will work only if the sender and destination are both in x2APIC mode.
Tracked-On: #3253
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
This patch introduces vLAPIC state for a VM. The VM vLAPIC state can
be one of the following
* VM_VLAPIC_X2APIC - All the vCPUs/vLAPICs (Except for those in Disabled mode) of this
VM use x2APIC mode
* VM_VLAPIC_XAPIC - All the vCPUs/vLAPICs (Except for those in Disabled mode) of this
VM use xAPIC mode
* VM_VLAPIC_DISABLED - All the vCPUs/vLAPICs of this VM are in Disabled mode
* VM_VLAPIC_TRANSITION - Some of the vCPUs/vLAPICs of this VM (Except for those in Disabled mode)
are in xAPIC and the others in x2APIC
Upon a vCPU updating the IA32_APIC_BASE MSR to switch LAPIC mode, this
API is called to sync the vLAPIC state of the VM. Upon VM creation and reset,
vLAPIC state is set to VM_VLAPIC_XAPIC, as ACRN starts the vCPUs vLAPIC in
XAPIC mode.
Tracked-On: #3253
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
is_xapic_enabled API returns true if vLAPIC is in xAPIC mode. In
all other cases, it returns false.
Tracked-On: #3253
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Remove static and inline attributes to the API is_x2apic_enabled
and declare a prototype in vlapic.h. Also fix the check performed on guest
APICBASE_MSR value to query vLAPIC mode.
Tracked-On: #3253
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
This patch changes the code in vlapic_set_apicbase for the following reasons
1) Better readability as it first checks if the new value programmed into
MSR is any different from the existing value cached in guest structures
2) Check if both bits 11:10 are set before enabling x2APIC mode for guest.
Current code does not check if Bit 11 is set.
3) Add TODO in the comments, to detail about the current gaps in
IA32_APIC_BASE MSR emulation.
Tracked-On: #3253
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
When the SOS kernel/pre-launched OS access the 0xCF8/0xCFC, it will cause
the vm-exit and then the hypervisor tries to emulate the PCI_cfg access.
0xCF8 write: The bdf/reg is captured. cache_reg = value & (0xFF);
0xCFC-0xCFF read/write: offset = address - 0xCFC. Then cached_reg + offset is
used as the offset to access the pci_cfg.
If the aligned reg is passed in 0xCF8 register, it can work well. But when
the unaligned reg is passed in 0xCF8 register, the cached_reg + offset will cause
that the incorrect pci_cfg offset is accessed. For example:
The cached_reg = 0x02(Device_ID offset) based on the value passed from 0xCF8
offset = 2 based on 0xCFC-0xCFF address.
Then cached_reg + offset is used as the offset(PCI_CMD_REG)
In fact the unaligned reg can work well on the real HW.
So the cached_reg should be aligned to handle the unaligned reg passed in
0xCF8 reg.
Tracked-On: #3249
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
V1:Initial Patch
Modularize vpic. The current patch reduces the usage
of acrn_vm inside the vpic.c file.
Due to the global natire of register_pio_handler, where
acrn_vm is being passed, some usage remains.
These needs to be a separate "interface" file.
That will come in smaller newer patch provided
this patch is accepted.
V2:
Incorporated comments from Jason.
V3:
Fixed some MISRA-C Violations.
Tracked-On: #1842
Signed-off-by: Arindam Roy <arindam.roy@intel.com>
Reviewed-by: Xu, Anthony <anthony.xu@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
This commit extract pm io handler registration code to register_pm_io_handler()
to reduce the cyclomatic complexity of create_vm() in order to be complied with
MISRA-C rules.
Tracked-On: #3227
Signed-off-by: Yan, Like <like.yan@intel.com>
When the lapic is passthru, vpic and vioapic cannot be used anymore. In
current code, user can still inject vpic interrupt to Guest OS, this is
not allowed.
This patch remove the vpic and vioapic initiate functions during
creating VM with lapic passthru. But the APIs in vpic and vioapic are
called in many places, for these APIs, follow the below principles:
1. For the APIs which will access uninitiated variables, and may case
hypervisor hang, add @pre to make sure user should call them after vpic or
vioapic is initiated.
2. For the APIs which only return some static value, do noting with them.
3. For the APIs which user will called to inject interrupt, such as
vioapic_set_irqline_lock or vpic_set_irqline, add condition in these
APIs to make sure it only inject interrupt when vpic or vioapic is
initiated. This change is to make sure the vuart or hypercall need not
to care whether lapic is passthru or the vpic and vioapic is initiated
or not.
Tracked-On: #3227
Signed-off-by: Conghui Chen <conghui.chen@intel.com>
On SDC scenario, SOS VM id is fixed to 0 so some hypercalls from guest
are using hardcoded "0" to represent SOS VM, this would bring issues
for HYBRID scenario which SOS VM id is non-zero.
Now introducing a new VM id concept for DM/VHM hypercall APIs, that
return a relative VM id which is from SOS view when create VM for post-
launched VMs. DM/VHM could always treat their own vm id is "0". When they
make hypercalls, hypervisor will convert the VM id to the absolute id
when dispatch the hypercalls.
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@Intel.com>
Changes:
- In current design, the hypercall is only allowed calling from SOS or
trusty VM, so separate the trusty hypercalls from dispatch_hypercall().
The vm parameter which referenced by hcall_xxx() should be SOS VM;
- do not inject #UD for hypercalls from non-SOS, just return -ENODEV;
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@Intel.com>
According to SDM vol1 13.3:
Write 1 to reserved bit of XCR0 will trigger GP.
This patch make ACRN behavior align with SDM definition.
Tracked-On: #3239
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
This patch fix potential null pointer dereference
1, will access null pointer if 'context' is null.
2, if entry already been added to the VM when add
intx entry for this vm, but parameter virt_pin
is not equal to entry->virt_sid.intx_id.pin. So
will saves this entry address to
vpin_to_pt_entry[entry->virt_sid.intx_id.pin] and
vpin_to_pt_entry[virt_pin]. In this case, this entry
will be freed twice.
Tracked-On: #3217
Signed-off-by: Tianhua Sun <tianhuax.s.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Host ACPI parsing is needed during initialization only, not in run time.
Hence we don't need to clear U flag for memory in reserved or ACPI type
E820 entries.
- move enable_smep() and enable_smap() to the end of init_pcpu_post(),
so stac()/clac() can be removed from any init code before this point.
- call init_seed() before init_pcpu_post(), and rmeove stac()/clac() from
init_seed().
Tracked-On: #3194
Signed-off-by: Zide Chen <zide.chen@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
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 VM IDs which is high or equal then CONFIG_MAX_VM_NUM are all
invalid VM IDs, the MACRO has never been referenced in code, so
remove it;
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@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>
Zephyr kernel is stripped ram image, its entry and load address
are explicitly defined in vm configurations, hypervisor will load
Zephyr directly based on these configurations.
Currently we only support boot Zephyr from protected mode.
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>
