This commit allows hypervisor to allocate cache to vcpu by assigning different clos
to vcpus of a same VM.
For example, we could allocate different cache to housekeeping core and real-time core
of an RTVM in order to isolate the interference of housekeeping core via cache hierarchy.
Tracked-On: #4566
Signed-off-by: Yan, Like <like.yan@intel.com>
Reviewed-by: Chen, Zide <zide.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
For a pre-launched VM, a region from PTDEV_HI_MMIO_START is used to store
64bit vBARs of PT devices which address is high than 4G. The region should
be located after all user memory space and be coverd by guest EPT address.
Tracked-On: #4458
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
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>
Since there is no RTVM requirement for sdc2 scenario, replace uuid
495ae2e5-2603-4d64-af76-d4bc5a8ec0e5 which is dedicated to RTVM with
615db82a-e189-4b4f-8dbb-d321343e4ab3
Tracked-On: #4472
Signed-off-by: fuzhongl <fuzhong.liu@intel.com>
Reviewed-by: Sun Victor <victor.sun@intel.com>
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>
- commit 69152647 ("hv: Use virtual APIC IDs for Pre-launched VMs")
enables virtual APIC IDs for pre-launched VMs thus xapic_phys is no
longer needed to force guest xAPIC to work in physical destination mode.
- HVC is not available in logical partition mode and "console=hvc0" should
be removed from guest Linux bootargs.
Tracked-On: #3854
Signed-off-by: Zide Chen <zide.chen@intel.com>
Acked-by: Victor Sun <victor.sun@intel.com>
Add severity definitions for different scenarios. The static
guest severity is defined according to guest configurations.
Also add sanity check to make sure the severity for all guests
are correct.
Tracked-On: #4270
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
rename the macro since MAX_PCPU_NUM could be parsed from board file and
it is not a configurable item anymore.
Tracked-On: #4230
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
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>
Change i915.domain_plane_owners and i915.avail_planes_per_pipe for
hybrid scenario;because some User vm(like:Ubuntu/Debian and WaaG)
doesn't support plane restriction; it will use PipeA by default.
Tracked-On: #3840
Signed-off-by: fuzhongl <fuzhong.liu@intel.com>
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>
There is plan that define each VM configuration statically in HV and let
DM just do VM creating and destroying. So DM need get vcpu_num
information when VM creating.
This patch return the vcpu_num via the API param. And also initial the
VMs' cpu_num for existing scenarios.
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>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
The vCOM2 of each VM is designed for VM communication, one VM could send
command or request to another VM through this channel. The feature will
be used for system S3/S5 implementation.
On Hybird scenario, vCOM2 of pre-launched VM will connect to vCOM2 of SOS_VM;
On Industry scenario, vCOM2 of post-launched RTVM will connect to vCOM2 of
SOS_VM.
Tracked-On: #3602
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Eddie Dong <eddie.dong@intel.com>
The settings of SOS VM COM1 which is used for console is board specific,
and this result in SOS VM COM2 which used for VM communication is also
board specific, so move the configure method from Kconfig to board configs
folder. The MACRO definition will be handled by acrn-config tool in future.
Tracked-On: #3602
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Eddie Dong <eddie.dong@intel.com>
Enable console vuart for the reset of VMs in industry scenario.
Tracked-On: #3370
Signed-off-by: Conghui Chen <conghui.chen@intel.com>
Reviewed-by: Eddie Dong <eddie.dong@intel.com>
When assgined a PCI PTDev to post-launched VM from SOS, using a pointer to point to
the real struct pci_vdev. When post-launched VM access its PTDev configure space in
SOS address space, using this real struct pci_vdev.
Tracked-On: #3475
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
Add a field (vdev_ops) in struct acrn_vm_pci_dev_config to configure a PCI CFG
operation for an emulated PCI device. Use pci_pt_dev_ops for PCI_DEV_TYPE_PTDEV
by default if there's no such configure.
Tracked-On: #3475
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Add emulated PCI device configure for SOS to prepare for add support for customizing
special pci operations for each emulated PCI device.
Tracked-On: #3475
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
Align SOS pci device configure with pre-launched VM and filter pre-launched VM's
PCI PT device from SOS pci device configure.
Tracked-On: #3475
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
pci_dev_config in VM configure stores all the PCI devices for a VM. Besides PT
devices, there're other type devices, like virtual host bridge. So rename ptdev
to pci_dev for these configure.
Tracked-On: #3475
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
In hybrid mode, pre-launched VM should have the highest severity to
handle platform reset, the flag should not be set in SOS VM;
Tracked-On: #3505
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
The vbar info which hard-coded in scenarios/logical_partition/pt_dev.c
is board specific actually, so move these information to
arch/x86/configs/$(CONFIG_BOARD)/pci_devices.h.
Please be aware that the memory range of vBAR should exactly match with
the e820 layout of VM.
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Per community requirement;up to three post-launched VM might be
needed for some automotive SDC system, so add SDC2 scenario to
satisfy this requirement.
Tracked-On: #3429
Signed-off-by: fuzhongl <fuzhong.liu@intel.com>
Reviewed-by: Victor Sun <victor.sun@intel.com>
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>
Define/Use variable in place of code to improve readability:
Define new local variable struct pci_bar *vbar, and use vbar-> in place of vdev->bar[idx].
Define new local variable uint64_t vbar_base in init_vdev_pt
Rename uint64_t vbar[PCI_BAR_COUNT] of struct acrn_vm_pci_ptdev_config to uint64_t vbar_base[PCI_BAR_COUNT]
Tracked-On: #3241
Signed-off-by: dongshen <dongsheng.x.zhang@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>
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>
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>
Different kernel has different load method, it should be configurable
in vm configurations;
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@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>
- 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>
For pre-launched VMs, currently we set all vbars to 0s initially in
bar emulation code, guest OS will reprogram the bars when it sees the bars are uninited (0s).
We consider this is not the right solution, change to populate the
vbars (to non zero valid pci hole address) based on the vbar base
addresses predefined in vm_config.
Store a pointer to acrn_vm_pci_ptdev_config in struct pci_vdev
Tracked-On: #3022
Signed-off-by: dongshen <dongsheng.x.zhang@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Previously we use Kconfig of DMAR_PARSE_ENABLED to choose pre-defined DMAR info
or parse it at runtime, at the same time we use MACRO of CONFIG_CONSTANT_ACPI
to decide whether parse PM related ACPI info at runtime. This looks redundant
so use a unified ACPI_PARSE_ENABLED Kconfig to replace them.
Tracked-On: #3107
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
vm_config.h has included types.h/acrn_common.h/vm_configurations.h,
acrn_common.h has included types.h, so remove the redundant includes;
Tracked-On: #2291
Signed-off-by: Victor Sun <victor.sun@intel.com>
The MACRO of CONFIG_CONSTANT_ACPI will be defined per scenario usage,
so move it from Kconfig to vm_configurations.h;
Tracked-On: #2291
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
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>
Rename structure acrn_vm_type to acrn_vm_load_order as it is used to
indicate the load order instead of the VM type.
Tracked-On: #2291
Signed-off-by: Conghui Chen <conghui.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
As commit info of 2362e58509, the guest flags
of GUEST_FLAG_IO_COMPLETION_POLLING work for POST_LAUNCHED_VM only, this
patch fix the wrong setting in SOS_VM;
Tracked-On: #2291
Signed-off-by: Victor Sun <victor.sun@intel.com>
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>
The name NORMAL_VM does not clearly reflect the attribute that these VMs
are launched "later". POST_LAUNCHED_VM is closer to the fact
that these VMs are launched "later" by one of the VMs launched by ACRN.
Tracked-On: #3034
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
- The pci device config is related to VM configurations, so move the device
mapping MACROs from pci_devices.h to vm_configurations.h. Also considering
pci_devices.h should be generated by offline parse tool, this code change
would decouple the relationship between VM configuration tool and target
paser tool;
- Another minor change is add post-fix in number for each PCI device subclass
name to make target parse tool interface friendly;
Tracked-On: #2291
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
In previous code, only for pre-launched VM, hypervisor would create
vuart console for each VM. But for post-launched VM, no vuart is
created.
In this patch, create vuart according to configuration in structure
acrn_vm_config. As the new configuration is set for pre-launched VM and
post-launched VM, and the vuart initialize process is common for each
VM, so, remove CONFIG_PARTITION_MODE from vuart related code.
Tracked-On: #2987
Signed-off-by: Conghui Chen <conghui.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Add vuart config in acrn_vm_config struct, support configuring 2 vuarts for
each VM. The first vuart is used to work as VM's console. The second vuart
is used to connect to other VM's vuart. When the port base for a vuart
is set to 0, hypervisor will not create this vuart.
Tracked-On: #2987
Signed-off-by: Victor Sun <victor.sun@intel.com>
Signed-off-by: Conghui Chen <conghui.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
The guest flags of GUEST_FLAG_IO_COMPLETION_POLLING work for NORMAL_VM only;
Tracked-On: #2291
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Currently, the previous configurations about guest_flags set by DM will
not be cleared when shutdown the vm. Then it might bring issue for the
next dm-launched vm.
For example, if we create one vm with LAPIC_PASSTHROUGH flag and shutdown it.
Then the next dm-launched vm will has the LAPIC_PASSTHROUGH flag set no matter
whether we set it in DM.
This patch clears all the DM set flags when shtudown vm.
Tracked-On: #2991
Signed-off-by: Kaige Fu <kaige.fu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Yan, Like