Currently acrn supports 2 non-contiguous HPA regions (HPA1 and HPA2), extend
the code to support 3rd non-contiguous HPA region (HPA3) for logical partition scenario
(hybrid scenario is not supported)
To keep things simple, current design has the following assumptions for
ve820 and ept mapping:
1. HPA2 will always be placed after HPA1
2. HPA3 will always be placed after HPA2
3. HPA1/HPA2/HPA3 don’t share a single ve820 entry.
(Create multiple entries if needed but not shared)
Tracked-On: #6145
Signed-off-by: dongshen <dongsheng.x.zhang@intel.com>
Currently config tool supports 2 non-contiguous HPA regions (HPA1 and HPA2), extend
the code to support 3rd non-contiguous HPA region (HPA3) for logical partition scenario
(hybrid scenario is not supported)
Tracked-On: #6145
Signed-off-by: dongshen <dongsheng.x.zhang@intel.com>
All releases of ACRN use the same CI docker image for testing the
documentation build. This creates a problem because some features used
in older ACRN releases are deprecated or behave differently with newer
versions of Sphinx and other tools. Add a check for the Sphinx version
to account for this, and update the .known-issues patterns for duplicate
declarations.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
ivshmem spec says that the size of BAR0 is 256 bytes. Windows
ivshmem driver will check the size of BAR0. It will refuse to
load the ivshmem driver if BAR0 size is not 256.
For post-launched VM hv land ivshmem BARs are allocated by
device model. For pre-launched VM hv land ivshmem BARs are
allocated by acrn-config tool. Both device model and acrn-config
tool should make sure that the BAR base addr are aligned to 4K
at least.
Tracked-On: #5717
Signed-off-by: Jian Jun Chen <jian.jun.chen@intel.com>
Reviewed-by: Fei Li <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
PCI spec said that BAR base should be naturally aligned. But on
ACRN if the bar size < PAGE_SIZE, BAR base should be aligned with
PAGE_SIZE. This is because the minimal size that EPT can map/unmap
is PAGE_SIZE.
Tracked-On: #5717
Signed-off-by: Jian Jun Chen <jian.jun.chen@intel.com>
Reviewed-by: Fei Li <fei1.li@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
Now, we use hash table to maintain intx irq mapping by using
the key generated from sid. So once the entry is added,we can
not update source ide any more. Otherwise, we can't locate the
entry with the key generated from new source ide.
For source id change, remove_remapping/add_remapping is used
instead of update source id directly if entry was added already.
Tracked-On: #5640
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
If we assign the mmio device address and size maliciously, this may crash
the HV, SOS even the UOS. This patch is a hot fix. The formal one needs
the config tool to configure the mmio device which we could pass through
and the HV check the mmio device by it.
Tracked-On: #5555
Signed-off-by: Li Fei1 <fei1.li@intel.com>
update all default pci_dev.c under
misc/vm_configs/scenarios/<scenario>/<platform> for non-xml compilation
Tracked-On: #5425
Signed-off-by: Yang Yu-chu <yu-chu.yang@intel.com>
After the SOS socket is closed, read() returns instantly with a return
value of 0. This causes life_mngr to flood the log file with the
following messages:
received msg []
received msg []
received msg []
...
Exit the program directly now if this is detected.
Tracked-On: #5429
Signed-off-by: Peter Fang <peter.fang@intel.com>
To enable the hv_land ivshmem for post-launched vm, the lanch script
needs to be cofigured accordingly.
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
paddr_guest2host may return NULL, this patch checks the return value
to avoid null pointer dereference.
Signed-off-by: Liu Long <long.liu@intel.com>
Tracked-On: #5514
paddr_guest2host can return NULL, but code paths in virtio
are not checking the return value.
_vq_record() initializes iov_base pointer using paddr_guest2host()
but there is nothing in the flow that checks for NULL.
Chane _vq_record to return -1 in case the address translation
has failed.
Tracked-On: #5514
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Memory BAR of ivshmem device is 64-bit, 2 BAR registers
are used, counting in one 32-bit MMIO bar and and one
32-bit vMSIX table bar, number of bars "nr_bars" shall
be 4 instead of 3.
Tracked-On: #5490
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
- fix bug in 'hcall_destroy_vdev()', the availability of
vpci device shall be checked on 'target_vm".
- refine 'vpci_update_one_vbar()' to avoid potential NULL
pointer access.
Tracked-On: #5508
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
It is found that SOS will reset the PCI devices under PCI
bridge 00:1c.0 when 00:1c.0 is exposed to SOS. If a PCI
device under 00:1c.0 is passed through to pre-launched VM,
it will be reset by SOS at startup hence the passthrough
will not work properly. This patch provides a workaround
by hiding PCI bridge 00:1c.0 from SOS in this case.
Tracked-On: #5346
Signed-off-by: Jian Jun Chen <jian.jun.chen@intel.com>
when HW platform like EHL use mmio type serial, do not need to hide
serial IO port for SOS
Tracked-On: #5498
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
Always trap for accessing IO port at CONFIG_SERIAL_PIO_BASE(0x3f8).
SOS will trap at IO 0x3f8 access because vuart[0]. When HW platform
has this serial IO port, and HV use it as debug shell, If vuart[0]
is not set, SOS & HV console input/output are mixed up.
So SOS should always trap at CONFIG_SERIAL_PIO_BASE
Tracked-On: #5498
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
When wrong BAR address is set for pci-vuart, OS may assign a
new BAR address to it. Pci-vuart BAR can't be reprogrammed,
for its fixed value.
Remove the fixed value of pci-vuart.
Tracked-On: #5491
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
Increase CONFIG_MAX_EMULATED_MMIO_REGIONS to 32, for more pci-vuarts.
Each pci-vuart vdev need 2 mmio BARs, if there are 8 pci-vuarts, they
need emulate 16 mmio regions.
But by default CONFIG_MAX_EMULATED_MMIO_REGIONS=16, that is not enough.
Tracked-On: #5491
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
Add an example to use "code=" and "vars=" in the dm parameters to launch
with OVMF split images.
Tracked-On: #5487
Signed-off-by: Peter Fang <peter.fang@intel.com>
Acked-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
In addition to a single OVMF image (OVMF.fd), split images
(OVMF_CODE.fd, OVMF_VARS.fd) can be used to facilitate VM management.
From the OVMF Whitepaper:
The variable store and the firmware executable are also available in
the build output as separate files entitled: "OVMF_VARS.fd" and
"OVMF_CODE.fd". This enables central management and updates of the
firmware executable, while each virtual machine can retain its own
variable store.
An example to launch acrn-dm with the split images:
--ovmf code=/usr/share/acrn/bios/OVMF_CODE.fd, \
vars=/usr/share/acrn/bios/OVMF_VARS.fd
v1 -> v2:
- use memory-mapped file I/O for writeback
- use fcntl to lock OVMF image files
Tracked-On: #5487
Signed-off-by: Peter Fang <peter.fang@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
The legacy vuart0 of any VMs inserts its base address declaration
anyway without checking whether it's disabled or enabled, and the
com base is hardcoded no matter what is specified in xmls.
Pull the legacy vuart enablement status based on scenario xml.
This reverts commit a8fe9b906a
Tracked-on: #5470
Signed-off-by: Yang, Yu-chu <yu-chu.yang@intel.com>
Bug fix:
1. The bdf were inserted in decimal. Fix it with hexadecimal
format.
2. The vuart vbdf will only take the dev which no used bdf has
the same dev. For example: If 00:01.1 is in used but not 00:01.0,
vuart vbdf will skip 00:01.0 and look for 00:02.0, 00:03.0 and so on.
Tracked-On: #5482
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Hypercall handlers for post-launched VMs automatically grab the vm_lock
in dispatch_sos_hypercall(). Remove the use of vm_lock inside the
handler.
Tracked-On: #5411
Signed-off-by: Peter Fang <peter.fang@intel.com>
Windows graphic driver obtains DSM address from in-BAR mmio register
which has passthroughed. Not like the other platforms obtained from
pci configure space register which has virtualized. So TGL has to
keep identical mapping to avoid trap mmio BAR to do the emulation.
To keep simple, this patch hardcode the TGL DSM region in vE820
table, this will cause memory waste here. In the near future, we
need refine the entire vE820 logic as it is hard to maintained
due to many reserved regions have introduced in recently.
Signed-off-by: Sun Peng <peng.p.sun@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Tracked-On: #5461
qemu xml has no devices list. Tool will receive the empty devices
list while parsing the "platform" xml. Remove the error of resolved
nested mmio address window that the input couldn't be None. Simply
return an None list.
Tracked-On:#5454
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
When libusb_control_transfer function return a negative number, because
the function clear_uas_desc's argument is unsigned int this will cause
unsigned integer conversion.
Tracked-On: #5463
Signed-off-by: Liu Long <long.liu@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Currently, ACRN only support shutdown when triple fault happens, because ACRN
doesn't present/emulate a virtual HW, i.e. port IO, to support shutdown. This
patch emulate a virtual shutdown component, and the vACPI method for guest OS
to use.
Pre-launched VM uses ACPI reduced HW mode, intercept the virtual sleep control/status
registers for pre-launched VMs shutdown
Tracked-On: #5411
Signed-off-by: dongshen <dongsheng.x.zhang@intel.com>
Like post-launched VMs, for pre-launched VMs, the ACPI reset register
is also fixed at 0xcf9 and the reset value is 0xE, so pre-launched VMs
now also use ACPI reset register for rebooting.
Tracked-On: #5411
Signed-off-by: dongshen <dongsheng.x.zhang@intel.com>
Add the 'reboot=acpi' kernel boot argument for pre-launched VMs
Add the code to sanity check if 'reboot=acpi' is specified in the
scenario files
If hardware reduced ACPI is detected, by default, Linux will set the reboot type to
use EFI for rebooting. "reboot=acpi" sets the reboot type to use ACPI for rebooting.
Tracked-On: #5411
Signed-off-by: dongshen <dongsheng.x.zhang@intel.com>
Change ACPI version from V3 to V5 to support hardware-reduced ACPI, which
is a V5 feature
Remove/obsolete the PM1X related stuff as they are not used for hardware-reduced
ACPI
Add the _S5 method in DSDT table
Using hardware-reduced mode allows to use a much simpler form of ACPI that
does not require supporting the legacy of previous versions of the specification
such as SCI IRQ.
Hardware-reduced mode is specified by setting the Hardware Reduced (HW_REDUCED_ACPI)
flag in FADT table.
If the HW_REDUCED_ACPI flag in the FADT table is set, OSPM will ignore fields related
to the ACPI HW register interface such as the PM1x control register. Instead, sleep
control/status registers can be used for system sleep state entry on hardware-reduced
ACPI systems.
Tracked-On: #5411
Signed-off-by: dongshen <dongsheng.x.zhang@intel.com>
So that guest VM can recognize and use ACPI reset register to reboot
No need to specify "Flags (decoded below)" in FADT template, iasl will
calculate and fill in this flag for us
Tracked-On: #5411
Signed-off-by: dongshen <dongsheng.x.zhang@intel.com>
A VM may transition to VM_PAUSED state while its console is being used.
Jump back to the HV shell if this happens so the console does not appear
stuck.
Tracked-On: #5411
Signed-off-by: Peter Fang <peter.fang@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
More than one VM may request shutdown on the same pCPU before
shutdown_vm_from_idle() is called in the idle thread when pCPUs are
shared among VMs.
Use a per-pCPU bitmap to store all the VMIDs requesting shutdown.
v1 -> v2:
- use vm_lock to avoid a race on shutdown
Tracked-On: #5411
Signed-off-by: Peter Fang <peter.fang@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Add two Kconfig pSRAM config:
one for whether to enable the pSRAM on the platfrom or not;
another for if the pSRAM is enabled on the platform whether to enable
the pSRAM in the pre-launched RTVM.
If we enable the pSRAM on the platform, we should remove the pSRAM EPT
mapping from the SOS to prevent it could flush the pSRAM cache.
Tracked-On: #5330
Signed-off-by: Qian Wang <qian1.wang@intel.com>
1.Modified the virtual e820 table for pre-launched VM. We added a
segment for pSRAM, and thus lowmem RAM is split into two parts.
Logics are added to deal with the split.
2.Added EPT mapping of pSRAM segment for pre-launched RTVM if it
uses pSRAM.
Tracked-On: #5330
Signed-off-by: Qian Wang <qian1.wang@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
dm: pSRAM: added a command line parameter "--psram" to enable pSRAM
support for post-launched RTVM
Added "--psram" in DM command line to enable pSRAM support for
post-launched RTVM
Tracked-On: #5330
Signed-off-by: Qian Wang <qian1.wang@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
