1.We added a function init_psram to initialize pSRAM as well as some definitions.
Both AP and BSP shall call init_psram to make sure pSRAM is initialized, which is
required by PTCM.
BSP:
To parse PTCT and find the entry of PTCM command function, then call PTCM ABI.
AP:
Wait until BSP has done the parsing work, then call the PTCM ABI.
Synchronization of AP and BSP is ensured, both inside and outside PTCM.
2. Added calls of init_psram in init_pcpu_post to initialize pSRAM in HV booting phase
Tracked-On: #5330
Signed-off-by: Qian Wang <qian1.wang@intel.com>
According 11.5.1 Cache Control Registers and Bits, Intel SDM Vol 3,
change CR0.CD will not flush cache to insure memory coherency. So
it's not needed to call wbinvd to flush cache in ACRN Hypervisor.
That's what the guest should do.
Tracked-On: #5330
Signed-off-by: Qian Wang <qian1.wang@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Improve the legacy vuart code. The legacy vuart insert the declaration
without checking if it's enabled. Refined the logic that if the legacy
is disabled, simply do not declare.
Tracked-On: #5425
Signed-off-by: Yang,Yu-chu <yu-chu,yang>
generic
Add console and communication vuarts to:
misc/vm_configs/xmls/config-xmls/generic/<scenario>.xml
misc/vm_configs/xmls/config-xmls/template/<scenario>.xml
Tracked-On: #5425
Signed-off-by: Yang, Yu-chu <yu-chu.yang@intel.com>
Check if the scenario xmls configure pci vuarts properly
Sanity check of scenario xml:
1. check the format of console and communication vuarts
2. legacy vuart0 and console vuart0 cannot be eabled at the same time
3. legacy vuart1 and communication vuart1 cannot be enabled at the
same time
4. Any vuart should not connect to any type of vuart0
5. Every vuart can only connect to enabled vuart<idx> (idx > 0)
Tracked-On: #5425
Signed-off-by: Yang,Yu-chu <yu-chu,yang>
Add pci vuart to launch script if the pci vuart is enabled.
Add pci vuart sanity check for launch script:
- vuart0 and console vuart cannot be enabled at the same time
- vuart1 cannot be eabled if the legacy vuart 1 is enabled
Tracked-On: #5425
Signed-off-by: Yang, Yu-chu <yu-chu.yang@intel.com>
- Find unused bdf for SOS and pre-launched VM's pci vuart if it's
enabled
- The vuart cannot detect the function difference, find the unused vbdf
based on "dev" increment
Tracked-On: #5425
Signed-off-by: Yang, Yu-chu <yu-chu.yang@intel.com>
Allocate unused vbar for pci based vuarts when the it's enabled for SOS
and/or pre-launched VMs.
- vuart needs 2 bar, both are 4k size
- for SOS, find unused vbar in the range which is assigned to pci host
bridge. The allocated vbar cannot have confilicts with any existing pci devices
- for pre-launched VMs, find unused vbar in the range 0x80000000 to
0xfffffff. The alloacted vbar cannot have confilicts with any
passthrough devices and mmio
Tracked-On: #5425
Signed-off-by: Yang, Yu-chu <yu-chu.yang@intel.com>
Preparing for upgrading to newer versions of doc building tools
including sphing, doxygen, breathe, docutils, etc. This PR's changes
still work find with the older tool versions, but should eliminate
issues found while moving to newer tool versions (later).
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
when fix the issue of _PM_SystemS5 with life_mngr fail,
the vuart1(tty) item was devided into two parts, the last
part "/dev/tty*" which need to get will be added to the
end, so it should be handled singly, but it will be added
to other item too, such as vuart1(pty).
Tracked-On:#5366
Signed-off-by: Shixiong Zhang <shixiongx.zhang@intel.com>
cleanup vpci structure when shutdown_vm to avoid use uninitialized data
after reboot.
Tracked-On: #4958
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Add cteate method for vmcs9900 vdev in hypercalls.
The destroy method of ivshmem is also suitable for other emulated vdev,
move it into hcall_destroy_vdev() for all emulated vdevs
Tracked-On: #5394
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
If acrn-dm create pci vuart with
'-s,<slot>,uart,vuart_idx:<value>', then acrn-dm will not
create pci uart at DM land, but create an vuart-pci virtual device
at HV land.
When create a HV land vuart-pci vdev, user must specify its vuart id.
Which is defined in vm_config, is the acrn_vm_pci_dev_config.vuart_idx
Tracked-On: #5394
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
if vuart type is pci-vuart, then use MSI interrupt
split vuart_toggle_intr() control flow into vuart_trigger_level_intr() &
trigger_vmcs9900_msix(), because MSI is edge triggered, no deassertion
operation. Only trigger MSI for pci-vuart when assert interrupt.
Tracked-On: #5394
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
Acked-by: Eddie Dong <eddie.dong@Intel.com>
support pci-vuart type, and refine:
1.Rename init_vuart() to init_legacy_vuarts(), only init PIO type.
2.Rename deinit_vuart() to deinit_legacy_vuarts(), only deinit PIO type.
3.Move io handler code out of setup_vuart(), into init_legacy_vuarts()
4.add init_pci_vuart(), deinit_pci_vuart, for one pci vuart vdev.
and some change from requirement:
1.Increase MAX_VUART_NUM_PER_VM to 8.
Tracked-On: #5394
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
The vuart_read()/vuart_write() are coupled with PIO vuart type. Move
the non-type related code into vuart_read_reg()/vuart_write_reg(), so
that we can re-use them to handle MMIO request of pci-vuart type.
Tracked-On: #5394
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Multiple devices could be nested under the same range. Skip remove if
the device is removed already
Tracked-On: #5437
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Changes:
1. assign 3 CPUs for WaaG on hybrid_rt scenario;
2. Passthrough NVME@9:0.0 for VM0 on hybrid_rt scenario;
3. Change rootfs from partition2 to partition3;
Tracked-On: #5390
Signed-off-by: Liang Yi <yi.liang@intel.com>
Acked-by: Victor Sun <victor.sun@intel.com>
Support enable ivshmem for SOS. Insert the ivshmem device information if
it is enabled.
1. get ivshmem vbar based:
- vbar[0] is size 0x100
- vbar[2] is specified MB size
2. get vbdf for ivshmem device
Tracked-On: #5426
Signed-off-by: Yang,Yu-chu <yu-chu,yang>
Add following to default output scenarios vm_configurations.c:
- pci_dev_num
- pci_devs = sos_pci_devs
Both was defineded in CONFIG_SOS_VM.
Tracked-On: #5426
Signed-off-by: Yang, Yu-chu <yu-chu.yang@intel.com>
- Refactor pci_dev_c.py to insert devices information per VMs
- Add function to get unused vbdf form bus:dev.func 00:00.0 to 00:1F.7
Add pci devices variables to vm_configurations.c
- To pass the pci vuart information form tool, add pci_dev_num and
pci_devs initialization by tool
- Change CONFIG_SOS_VM in hypervisor/include/arch/x86/vm_config.h to
compromise vm_configurations.c
Tracked-On: #5426
Signed-off-by: Yang, Yu-chu <yu-chu.yang@intel.com>
Allocate unused vbar for SOS and pre-launched VMs.
- For SOS, find unused vbar in the range which is assigned to pci host
bridge. The allocated vbar cannot have confilicts with any existing pci devices
- For pre-launched VMs, find unused vbar in the range 0x80000000 to
0xfffffff. The alloacted vbar cannot have confilicts with any
passthrough devices and mmio.
Tracked-On: #5426
Signed-off-by: Yang, Yu-chu <yu-chu.yang@intel.com>
automatically get PTCT table from native environment for the usage
of pre-launched VMs.
Tracked-On: #5418
Signed-off-by: Shuang Zheng <shuang.zheng@intel.com>
fill physical PTCT table into pre-launched vACPI table when PSRAM
is configured to passthrough to pre-launched RTVM.
Tracked-On: #5418
Signed-off-by: Shuang Zheng <shuang.zheng@intel.com>
add PSRAM configs in xmls, only enable PSRAM and passthrough to
pre-launched RTVM for hybrid_rt scenario on tgl-rvp board.
Tracked-On: #5418
Signed-off-by: Shuang Zheng <shuang.zheng@intel.com>
Config tool UI will do mutually exclusive check the legacy vuart 0/1 and
PCI vuart 0/1 to make sure there is no legacy vuart and PCI vuart are
used at the same time for VMs.
Tracked-On: #5394
Signed-off-by: Shuang Zheng <shuang.zheng@intel.com>
Add PCI VUART config for post-launched VMs in launch config UI. Users
can configure the console_vuart, configure or dynamically add or remove
communication_vuart based on the communication vuarts which are configured
from the scenario xml.
Tracked-On: #5394
Signed-off-by: Shuang Zheng <shuang.zheng@intel.com>
Add PCI VUART dynamic config for VMs in scenario config UI, keep legacy
VUART config. PCI vuart base can be set to INVALID_PCI_BASE and PCI_VUART;
users will configure the target_vm_id and target_vuart_id when PCI vuart
base is set to PCI_VUART; users can dynamically add or delete PCI vuart
for VMs.
Tracked-On: #5394
Signed-off-by: Shuang Zheng <shuang.zheng@intel.com>
- Explicitly reserve memory regions based on the input E820 map
- Revert "ovmf: reserve e820 table for PTCM"
Tracked-On: #5442
Signed-off-by: Peter Fang <peter.fang@intel.com>
We don't reserve PCI MMIO in e820 Table, it's included in DSDT ACPI Table.
About 0xA0000 - 0x100000 entry, we don't have any ACPI Table touch this region.
So we could remove it too.
After this change, we could only pass the reserved e820 table which we must
reserve to OVMF. In this case, the OVMF could trust ACRN-DM and pass the
reserved e820 table to guest instead of dropping it.
This patch needs the corresponding modify in OVMF. Otherwise, the guest could
not boot.
Tracked-On: #4550
Signed-off-by: Li Fei1 <fei1.li@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
The new (1.8.17) release of doxygen is complaining about errors in the
doxygen comments that were's reported by our current 1.8.13 release.
Let's fix these now. In a separate PR we'll also update some
configuration settings that will be obsolete, in preparation for moving
to this newer version.
[External_System_ID]ACRN-6774
Tracked-On: #5385
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
In pre-launched VM the GPA of vmsix BAR which is used for vmsix
over msi is calculated/allocated by acrn-config tool. The GPA
needs to be assigned to vdev when vdev is initialized. The
assignment is only needed for pre-launched VM. For SOS kernel
will reprogram the Bar base when startup. For post-launched VM
the Bar GPA will be assigned by device model via hypercall.
Tracked-On: #5316
Signed-off-by: Jian Jun Chen <jian.jun.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
When init_vmsix_on_msi is called during the initialization of a pt
device, the vmsix bar used for vmsix over msi is just created. No
mapping/unmapping is done and pci_vdev_write_vbar should be called
instead of vdev_pt_write_vbar at the time. Currently the Bar mapping
is delayed till OS sizing the Bar. Backup vbar base_gpa to mmio_gpa
is not required here becuase it will be done later when Bar mapping.
Tracked-On: #5316
Signed-off-by: Jian Jun Chen <jian.jun.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
changes:
1. Change SOS VM rootfs to nvme0;
2. Change hybrid_rt scenario VM0 mem size to 1GB;
Tracked-On: #5238
Signed-off-by: Victor Sun <victor.sun@intel.com>
