If passthrugh TPM2 is enabled and the log area is present, allocates
the log_area_start_address with the size log_area_minimum_length(256K).
Tracked-On: #6320
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Create python script tpm2 which parse the tpm2 acpi table datas. Add
this parsed data to the <device id="MSFT0101" description="TPM 2.0 Device"> of board.xml.
Tracked-On: #6320
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
It is seen occasionally that a memory/port BAR of a PCI device is
programmed with the address 0 which is clearly invalid. This patch
gracefully handles this case by printing an error to warn the users that
this device cannot be passed through to any VM.
Tracked-On: #6298
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
According to section 19 of ACPI spec 6.4, the following clauses open name
scopes (in addition to the Scope clauses).
- Function
- Device
- Method
- Power Resource
- Thermal Zone
The current AML parser only opens a scope when parsing DefMethod and
DefDevice, however. This patch fixes the AML parsing by opening a scope on
visiting a DefPowerRes or DefThermalZone clause.
Note: Functions in ASL are equivalent to Methods at AML level.
Tracked-On: #6298
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
The current ConditionallyUnregisterSymbolVisitor has the following two
issues.
1. The visitor will crash when a DefIfElse node is not fully parsed due
to failed deferred expansion.
2. Nested DefIfElse of disabled blocks are still checked and one of its
branch may still take effect.
This patch fixes those issues by checking the predicates of a DefIfElse
block only when conditionally_hidden is False and check existence of
TermList and DefElse clauses.
Tracked-On: #6298
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
When parsing a sequence of clauses, it is not necessary to peek an opcode
from the current stream unless that sequence starts with one. Peeking an
opcode is even an error when the actual clause is empty (e.g. as a
TermList).
This patch makes the SequenceFactory only peeking at the next opcode when
the grammar expects one.
Tracked-On: #6298
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This patch refines the AML parser to improve its readability and
performance in the following ways.
1. A Tree object now has the parts of the corresponding object being
member fields. As an example, a Tree with label `DefMethod` now has
members `NameString`, `MethodFlags` and `TermList`.
2. It is now possible to assign names each part of an object. The grammar
is updated to assign different names to the parts with the same type
in the same object.
Tracked-On: #6298
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
The current ACPI AML parser can generate incorrect AST if a DSDT/SSDT
satisfies the following:
1. The body of a method invokes a NameString that is defined later.
2. Before the method that NameString is also defined but in an outer
scope and with a different number of parameter.
Since method bodies hardly define any further symbol that is referenced
outside the method itself, this patch forces the parsing of method bodies
to be deferred to the second pass when all symbols have been declared.
Tracked-On: #6298
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
The current implementation of I/O buffers have the following issues.
1. I/O buffers are filled with values on creation. This may be fine for
memory-mapped I/O regions, but could be a problem to port I/O regions
and indexed I/O regions.
2. While not commonly seen, it IS witnessed that some devices only allow
its MMIO registers to be accessed with certain width. Accessing such
registers with a larger width will not be handled by the device,
causing SW to get all 1's rather than the actual values in these
registers.
This patch resolves the issues above as follows. I/O buffers now do not
access any register on creation. Instead, the register is accessed only
upon requests. Also the access width of these registers are followed to
ensure that the registers are accessed properly.
Tracked-On: #6298
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
DefDevide is now enountered when interpreting host DSDT/SSDT. This patch
implements the interpretation.
Tracked-On: #6298
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
The current implementation of the AML interpreter continues interpreting a
method after meeting a DefReturn object, which is incorrect. This patch
fixes this issue.
Tracked-On: #6298
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
If TPM device is passthrough to pre-launched VM, need check its
start method and event log settings in native TPM2 ACPI table.
Because when connect different TPM devices, TPM start method can
change in native ACPI table. And event log address change in native
ACPI table is expected by BIOS updating. Need fixup pre-launched
VM's ACPI table and vm_config if they are misaligned with native
platform. We add acrn_vm_fixup() in prepare_vm(), where the acrn_vm
structure is not created. This is suitable for checking between
vm_config and HW real configurations, and try fixup for native ACPI
updating.
Tracked-On: #6320
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
mmiodev can have more than one mmio resource, so mmiores[3] is embedded
into mmiodev
Tracked-On: #6320
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
The vRSDP region of pre-launched VM is located at 0xf2400, it could be
overlapped with the memory space of the raw image so be overriden by
raw image loading. In this case VM would be failed to find ACPI table.
This patch fix this issue by loading raw image first and then building
vRSDP later.
Tracked-On: #6305
Signed-off-by: Victor Sun <victor.sun@intel.com>
Remove hybrid.xml, hybrid_rt.xml, logical_partition.xml and
industry_launch_2uos.xml files because validation team found
that these scenario files not working. And these documents will be
resubmitted after them are verified successfully.
Tracked-On: #6244
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
1. Update python script name that is executed to generate board xml file
from run.py to cli.py in README file.
2. Update the OS requirement under native Linux in
misc/config_tools/board_inspector/README file.
Tracked-On: #6134
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
This reverts commit 24af7f8f9d which leaves
MAX_MSIX_TABLE_NUM item as empty for most of platforms except ehl-crb-b and
expect config tool to calculate a correct MAX_MSIX_TABLE_NUM for hypervisor
use. Unfortunately current config tool just calculate maximum native MSIX
number without evaluating the maximum MSI vectors that ACRN needed for vMSIX
emulation, thus introduce big risk on the device vMSIX table initialization.
If customer has special device that need larger MAX_MSIX_TABLE_NUM to enable
ACRN, he can input the number in his own scenario file.
Tracked-On: #6186
Signed-off-by: Victor Sun <victor.sun@intel.com>
The multiboot.h has not been deleted in commit of "HV: modularization:
rename multiboot.h to boot.h" by mistake when do rebase, remove it.
Tracked-On: #5661
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Use the teardown API as the unify free console API in virtio console,
in case the console have already been freed by deinit when the teardwon
API is called.
Tracked-On: #6157
Signed-off-by: Liu Long <long.liu@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
1. Update the value of the tag MAX_MSIX_TABLE_NUM from 64 to empty
for all scenario xml except ehl-crb-b board.
2. Update the value of the tag MAX_MSIX_TABLE_NUM to 96 for the
scenario xml on the ehl-crb-b board.
Tracked-On: #6186
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
Update the value of the tag MAX_PT_IRQ_ENTRIES from 64 to 128
in TGL-RVP scenario xml.
Tracked-On: #6185
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
Remove the AlwaysBreakTemplateDeclarations setting in clang-format file
to fix the issue about "make defconfig".
Tracked-On: #6199
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
A vmsix supported passthrough device expects the first unused bar region
for vmsix. Pop the first unused_bar_index in gpa.py instead.
Reference code: init_vmsix_on_msi of hypervisor\dm\vpci\vmsix_on_msi.c
Tracked-On: #6192
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Get and save native root port's max payload in dev cap register in
vrp_config data structure which will be used to configure vrp's max
payload by hv.
Tracked-On: #5915
Signed-off-by: Rong Liu <rong.l.liu@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
It seems important that passthru device's max payload settings match
the settings on the native device otherwise passthru device may not work.
So we have to set vrp's max payload capacity as native root port
otherwise we may accidentally change passthru device's max payload
since during guest OS's pci device enumeration, pass-thru device will
renegotiate its max payload's setting with vrp.
Tracked-On: #5915
Signed-off-by: Rong Liu <rong.l.liu@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Suppose the current vcpu is 0, the other vcpus (1, 2, 3) may wait on the
"get_split_lock", the current vcpu need clear the ACRN_REQUEST_SPLIT_LOCK
explicitly here after finishing the emulation. Otherwise, it make cause
dead lock. for example:
1. Once vcpu 0 "put_split_lock", let's say vcpu 1 will "get_split_lock".
2. vcpu 1 call "vcpu_make_request" to pause vcpu 0, 2, 3.
3. vcpu 1's VCPU_EVENT_SPLIT_LOCK is still not cleared because
the vcpu 0 called "vcpu_make_request" ever.
4. All vcpus will wait for VCPU_EVENT_SPLIT_LOCK in acrn_handle_pending_request.
We should avoid this dead lock case.
Please note: this patch is only for release 2.5 test.
Tracked-On: #6051
Signed-off-by: Jie Deng <jie.deng@intel.com>
On the original WaaG, split-lock was rarely triggered by WaaG kernel.
We didn't find any problems when removing this patch. So this patch
was discarded in the final patch set merge.
Now, the latest Windows graphic driver will trigger lots of
split-lock very frequently. The test team reports this patch will
affect the stability.
Add this patch back to improve stability by using a dedicate lock.
Please note: This patch is only for release 2.5 test.
Tracked-On: #6051
Signed-off-by: Jie Deng <jie.deng@intel.com>
return value 'err' of mmio_rb_lookup() being 0 ensures
'entry' is not NULL, hence checking it before 'free(entry)'
is unnecessary.
Tracked-On: #6157
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
The trb pointer may be NULL when get the address from user space,
add the pointer check before use the trb.
Tracked-On: #6172
Signed-off-by: Liu Long long.liu@intel.com
Reviewed-by: Shuo A Liu shuo.a.liu@intel.com
Acked-by: Yu Wang yu1.wang@intel.com
Refine get_pt_intx_table. The method parse the <pt_inx> of scenario and
append the pair of phys_gsi and virt_gsi if there is any.
Refine check_pt_intx. Add a condition that the method returns if the
phys_gsi and virt_gsi are empty dictionary.
Tracked-On: #6178
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
We need to deny accesses from SOS to the HV owned UART device, otherwise
SOS could have direct access to this physical device and mess up the HV
console.
If ACRN debug UART is configured as PIO based, For example,
CONFIG_SERIAL_PIO_BASE is generated from acrn-config tool, or the UART
config is overwritten by hypervisor parameter "uart=port@<port address>",
it could run into problem if ACRN doesn't emulate this UART PIO port
to SOS. For example:
- none of the ACRN emulated vUART devices has same PIO port with the
port of the debug UART device.
- ACRN emulates PCI vUART for SOS (configure "console_vuart" with
PCI_VUART in the scenario configuration)
This patch fixes the above issue by masking PIO accesses from SOS.
deny_hv_owned_devices() is moved after setup_io_bitmap() where
vm->arch_vm.io_bitmap is initialized.
Commit 50d852561 ("HV: deny HV owned PCI bar access from SOS") handles
the case that ACRN debug UART is configured as a PCI device. e.g.,
hypervisor parameter "uart=bdf@<BDF value>" is appended.
If the hypervisor debug UART is MMIO based, need to configured it as
a PCI type device, so that it can be hidden from SOS.
Tracked-On: #5923
Signed-off-by: Zide Chen <zide.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
e820_alloc_memory() splits one E820 entry into two entries. With vEPT
enabled, e820_alloc_memory() is called one more. On some platforms, the
e820 entries might exceed 32.
Enlarge E820_MAX_ENTRIES to 64. Please note, it must be less than 128
due to constrain of zeropage. Linux kernel defines it as 128.
Tracked-On: #6168
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
The bootargs module represents a string buffer and there is a NULL char at
the end so its size should not be calculated by strnlen_s(), otherwise the
NULL char will be ignored in gpa copy and result in kernel boot fail;
Tracked-On: #6162
Signed-off-by: Victor Sun <victor.sun@intel.com>
SBL would load multiboot modules to the maximum usable ram below 4GB, in this
case the SOS kernel would be failed to load because no room for kernel in
the range of end of modules and MEM_4G. So kernel must be relocated to the
range of MEM_1M and start of modules, or other appropriate place according
to modules layout.
Tracked-On: #6162
Signed-off-by: Victor Sun <victor.sun@intel.com>
When hypervisor boots, the multiboot modules are loaded by bootloader(GRUB)
from HPA 0x100000 in order. The space range of pre-launched VM modules is also
exposed to SOS VM, so SOS VM kernel might pick this range to extract kernel
when KASLR enabled. This would corrupt pre-launched VM modules and result in
pre-launched VM boot fail.
This patch will try to fix this issue. The SOS VM will not be loaded to guest
space until all pre-launched VMs are loaded successfully.
Tracked-On: #5879
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
We should not hardcode the VM ramdisk load address right after kernel
load address because of two reasons:
1. Per Linux kernel boot protocol, the Kernel need a size of
contiguous memory(i.e. init_size field in zeropage) from
its load address to boot, then the address would overlap
with ramdisk;
2. The hardcoded address could not be ensured as a valid address
in guest e820 table, especially with a huge ramdisk;
Also we should not hardcode the VM kernel load address to its pref_address
which work for non-relocatable kernel only. For a relocatable kernel,
it could run from any valid address where bootloader load to.
The patch will set the VM kernel and ramdisk load address by scanning
guest e820 table with find_space_from_ve820() api:
1. For SOS VM, the ramdisk has been loaded by multiboot bootloader
already so set the load address as module source address,
the relocatable kernel would be relocated to a higher address
after hypervisor and all multiboot modules to avoid guest
memory copy corruption;
2. For pre-launched VM, the kernel would be loaded to pref_address
first. If kernel end address is higher than maximum ramdisk
address limit, hypervisor would try to locate ramdisk load
address from 0x100000 to kernel load address; If kernel end
address is lower than maximum ramdisk address limit, hypervisor
would try to locate ramdisk address from kernel end address
to the maximum ramdisk address limit under 4GB;
Tracked-On: #5879
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
The SOS VM should not use host efi memmap directly, since there are some
memory ranges which reserved by hypersior and pre-launched VM should not
be exposed to SOS VM. These memory ranges should be filtered from SOS VM
efi memmap, otherwise it would caused unexpected issues. For example, The
SOS kernel kaslr will try to find the random address for extracted kernel
image in EFI table first. So it's possible that these reserved memory is
picked for extracted kernel image. This will make SOS kernel boot fail.
The patch would create efi memmory map for SOS VM and pass the memory map
info to zeropage for loading SOS VM kernel. The boot service related region
in host efi memmap is also kept for SOS VM so that SOS VM could have full
capability of EFI services as host.
Tracked-On: #5626
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Previously the load GPA of LaaG boot params like zeropage/cmdline and
initgdt are all hard-coded, this would bring potential LaaG boot issues.
The patch will try to fix this issue by finding a 32KB load_params memory
block for LaaG to store these guest boot params.
For other guest with raw image, in general only vgdt need to be cared of so
the load_params will be put at 0x800 since it is a common place that most
guests won't touch for entering protected mode.
Tracked-On: #5626
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
The API would search ve820 table and return a valid GPA when the requested
size of memory is available in the specified memory range, or return
INVALID_GPA if the requested memory slot is not available;
Tracked-On: #5626
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
The memory range of [0xA0000, 0xFFFFF] is a known reserved area for BIOS,
actually Linux kernel would enforce this area to be reserved during its
boot stage. Set this area to usable would cause potential compatibility
issues.
The patch set the range to reserved type to make it consistent with the
real world.
BTW, There should be a EBDA(Entended BIOS DATA Area) with reserved type
exist right before 0xA0000 in real world for non-EFI boot. But given ACRN
has no legacy BIOS emulation, we simply skipped the EBDA in vE820.
Tracked-On: #5626
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Hypervisor use e820_alloc_memory() api to allocate memory for trampoline code
and ept pages, whereas the usable ram in hv_e820 might include efi boot service
region if system boot from uefi environment, this would result in some uefi
service broken in SOS. These boot service region should be filtered from
hv_e820.
This patch will parse the efi memory descriptor entries info from efi memory
map pointer when system boot from uefi environment, and then initialize hv_e820
accordingly, that all efi boot service region would be kept as reserved in
hv_e820.
Please note the original efi memory map could be above 4GB address space,
so the efi memory parsing process must be done after enable_paging().
Tracked-On: #5626
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
When hypervisor boot from efi environment, the efi memory layout should be
considered as main memory map reference for hypervisor use. This patch add
function that parses the efi memory descriptor entries info from efi memory
map pointer and stores the info into a static hv_memdesc[] array.
Tracked-On: #5626
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
