1. check if VMX feature is enabled in the BIOS setting.
If disabled, board inspector will show error message.
2. check if Hyper-Threading is enabled in the BIOS setting.
If enabled, board inspector will show warning message.
3. check if VT-d is enabled in the BIOS setting.
If disabled, board inspector will show error message.
v2-->v3:
Use the class names instead of addresses, and invoke the rdmsr method
of each class.
v1-->v2:
1. For the Hyper-Threading BIOS check, update the log level to the warning.
2. For VMX invalid BIOS check, the XDS does the actual check,
the board inspector only collects information.
Tracked-On: #6689
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Add CPU capability checks.
If a feature is not supported on this processor, the board inspector
will show error message because it would impact ACRN’s ability
to function properly.
v3-->v4:
Update the error messages.
v2-->v3:
1. For VMX features, split each feature as a separate property, capability
checks in XML schema will then check all those features.
2. Use the class names instead of addresses, and invoke the rdmsr method
of each class.
v1-->v2:
1. Define each register as a class inheriting the `MSR` class defined
in platformbase.py, and define each bit as fields of that class.
2. The board inspector simply collects the CPU capability and attribute,
and the XSD does the actual check
Tracked-On: #6689
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
This patch extracts all serial ttys in the native environment and updates
the XML schema to specify the XPATH that evaluates to the available ttys
for users to choose as the hypervisor console port.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Add a new extractor 70-device-classes.py which extracts virtio device
input basic information such as: name and phys.
An example:
<device_classes>
<inputs>
<input>
<name>Power Button</name>
<phys>LNXPWRBN/button/input0</phys>
</input>
<inputs>
</device_classes>
Tracked-On: #6690
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
This patch adds the BDF (in the format BBBB:DD.F) of each PCI device into
its description, which helps the configurator to fetch all available PCI
devices via XPATH rather than text manipulating functions.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
category based on different log levels:
1) If the board inspector show CRITICAL error messages, it means that the
board inspector tool exit instantly and generate no file.
2) If the board inspector show ERROR messages, it means that the board
inspector will generate the board XML file successfully, but several conditions
may result in ACRN build or boot failure cannot continue execution due to the error.
3) If the board inspector show WARNING messages, this means that the board inspector
generate the board XML file successfully, but this board XML file is lack of
some feature which could still boot ACRN but loss some features.
4) If the board inspector show INFO messages, this means that board inspector
printed out some normal information.
5) If the board inspector show DEBUG messages, this means that it is used to
debug board inspector workflow.
v1->v2
1. Keep the assertions or exceptions under the acpiparser, inspectorlib
and smbiosparser directory.
2. Exit after all check_deps() completes instead of any unsatisfied dep
is identified.
3. As Amy's advice, Replace the message "{board_xml} saved successfully" with
the message "SUCCESS: Board configuration file <file name> generated successfully
and saved to <path>."
To do:
Print all messages using the colored font.
Tracked-On: #6689
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
In 10-processors.py, level_types is an unordered dictionary from level type
encodings to human-readable terms, not a list. It is thus illegal to access the
highest level using the `[-1]` notation.
This patch fixes this by calculating the highest level in level_types and use
that level as the index instead.
Tracked-On: #6689
Fixes: b5b22bf98 ("board_inspector: avoid hard-coded topo level names")
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
While the terms to refer to CPU topology levels are originally borrowed
from MSR listings in SDMs (i.e. thread, core, die and package), we now
align the topology information with the CPUID topology enumeration
leaf (which does not have a "package" level) in the
implementation. However, some hard-coded level types are not updated
accordingly, leading to strangely organized nodes in the generated board
XML.
This patch refines the CPU extractor of the board inspector by removing
such hard code. Also the XPATH counting the total number of threads is
refined to tolerate the variance of reported intermediate levels.
Tracked-On: #6689
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
INTx routing can be specified in ACPI PRT (PCI Routing Table) in two ways:
1. By an absolute interrupt line from the global interrupt pool.
2. By a device object and an index to its interrupt resource.
The board inspector today only encodes the source object of an interrupt
pin routing in XML device resource descriptors, which is incomplete if the
source is a device object (i.e. case 2 above).
This patch adds the index from PRT to device resource nodes as well.
Tracked-On: #7058
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
Today we assume a device node under /sys/devices/pciXXXX:XX/ always contain
a `config` file which shows the configuration space of the PCI
functions. This seems not the case for, at least, Non-Transparent
Bridge (or NTB).
This patch checks the existence of the `config` file and skips PCI
functions which do not contain one.
Tracked-On: #6902
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
Add a new extractor 40-acpi-tables.py which extracts ioapics basic
information such as: ioapic id, address, gsi base and gsi number.
An example:
<ioapics>
<ioapic id="0x2">
<address>0xfec00000</address>
<gsi_base>0x0</gsi_base>
<gsi_number>240</gsi_number>
</ioapic>
</ioapics>
Tracked-On: #6986
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
ACPI device drivers use both _HID and _CID to identify devices they
match. This patch copies _CID objects to vACPI devices so that guest
drivers can recognize the passthrough devices properly.
Tracked-On: #6288
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Extract the log area address from TPM2 acpi table and add node
log_area_start_address to board.xml. This emelment is used by host_pa of
mmiodevs.
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 typical in AML resource descriptors to have 0-length region
descriptors which are typically templates of resources that are not
assigned on the current platform. For such regions, the `base + length - 1`
formula does not calculate the max of the region properly.
This patch updates the resource descriptor parsers to use max = min when
the length of the region is 0.
Tracked-On: #6287
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
When parsing an AML object representing a host bridge, the current board
inspector may encounter the following issues:
1. The host DSDT may contain multiple host bridge instances, with some of
them not being present. In this case the _BBN of these instances may
evaluate to the same value that coincide with the bus assigned to an
existing host bridge, leading to multiple PCI bus nodes with the same
bus number and thus confusion in later information extraction phases.
2. Methods of a host bridge may refer to the PCI configuration space of
itself (which is typically Device 0, Function 0 under that
bus). However, such objects may not have an _ADR object as the bus
number is encoded by the _BBN object instead.
This patch fixes the issues above.
Tracked-On: #6287
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
According to the specification, the _MAX of memory address space resource
descriptors may not necessarily be _MIN + _LEN - 1. Typically the resource
locates at the low end of the region specified by _MIN and _MAX. This patch
makes the ACPI extractor always calculating the end of a memory region
using _MIN and _LEN instead.
Tracked-On: #6287
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This patch updates the board inspector to collect the bits of physical and
linear addresses of the processors and generate this information to the
board XML for further uses at configuration phase.
Tracked-On: #6292
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
It is witnessed on some boards that the device status (as is reported by
the _STA object) returns 0 while the device object is still useful for
pass-through devices. The original implementation, however, assumes that
only a device is a non-zero status is useful as long as the _STA object
exists.
This patch makes this filtering disabled by default and adds a command-line
argument `--check-device-status` to enable this filtering. As disabled or
non-present devices can have empty resources, the sorting algorithm is
updated accordingly to gracefully handle such descriptors.
This patch is added in v3 of the series.
Tracked-On: #6287
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Servers typically have multiple peer host bridges that need to be scanned
separately. This patch extends the PCI information extractor to visit all
PCI host bridges by enumerating /sys/devices/pci* directories.
Tracked-On: #6292
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
It is seen that the BAR in the PCI configuration space of a device can be
cleared when the device is put to D3. This patch resumes a device not in D0
before parsing its configuration space in order to collect accurate
information.
This patch is added in v2 of the series.
Tracked-On: #6287
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
AML allows devices defined in an ACPI namespace to have inter-dependency,
i.e. a method defined in one device can refer to objects in other
devices. While such inter-dependency is common in device manipulation
methods, device identification and configuration methods, such as _CRS, may
depend on other devices as well.
An example we have already met is a PCS (Physical Coding Sublayer) which
calculates resource descriptors by accessing the PCI configuration space of
the accompanying Ethernet controller. Without the ACPI object describing
the PCS, a driver of the Ethernet controller may refuse to initialize.
This patch adds a preliminary dependency analyzer to detect such
inter-device dependency. The analyzer walks through the reference chains of
an object, identifying whether the referenced objects are operation fields
of a device. Depending on the result of this analysis, the board XML is
refined as follows.
* When an object (probably a method) references such fields, the original
object definition in host DSDT/SSDTs will be copied in the AML template
so that they still work in VMs where the operation fields may be
virtualized. Such objects will be referred to as "copied objects"
hereinafter.
* The objects that are **directly** referenced by a copied object is
added in the AML template as well. Such objects still belong to devices
where they are originally defined in the host ACPI namespace. Their
definition, however, may be copied or replaced with constant values,
depending on the dependency analysis on these objects.
* Nodes with the "dependency" tag are added under "device" nodes in the
board XML, allowing the configuration tools to follow the device
dependency chain when generating vACPI tables. These nodes only
represent direct dependencies; indirect dependencies can be inferred by
following those direct ones.
The current implementation does not allow objects being added to AML
templates if they refer to any of the following.
* Global objects, i.e. objects not belonging to any device. Such objects
tend to encode system-wide information, such as the ACPI
NVS (Non-Volatile Storage) or its fields.
* Methods with parameters.
Objects with such references are thus being hidden from guest software,
just like how they are invisible in the current implementation.
This patch is added in v2 of the series.
v2 -> v3:
* Also collect dependencies due to providing or consuming resources.
* Refactor the dependency detection logic for clarity.
Tracked-On: #6287
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This patch adds AML template (in XML hexBinary format) for each device to
board XMLs. For now these templates contain the following objects if they
exists in the physical DSDT:
- Device identification objects: _ADR, _HID, _UID and _STR
- _CRS which encodes the current resources consumed by the device
- _STA which encodes the status of the device
An AML template is always a DefScope with a single DefDevice so that they
can be appended anywhere in the vDSDT.
v1 -> v2:
* Remove the temporary visitor that collects cross-device dependencies. Such
check will be replaced with another visitor introduced in the next patch.
v2 -> v3:
* The AML templates are now DefDevice objects with their names being the
full namepath. The vDSDT generator will take care of this and organize
the objects properly.
Tracked-On: #6287
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
/usr/share/pci.ids.gz is another typical path to the pci.ids file of the
lspci tool which is used in Yocto-based systems. This patch adds this path
as another candidate when searching for pci.ids. The builtin gzip module is
used to open this file.
Tracked-On: #6287
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
In addition to the mandatory _HID (Hardware ID), the ACPI spec also defines
an optional _CID (Compatible ID) object for device identification.
This patch enhances the ACPI extractor by parsing the _CID objects of devices as
well.
Tracked-On: #6320
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This patch adds interrupt pin related information into the board XML,
including:
* The PCI routing table in ACPI DSDT/SSDT are parsed and generated into
the board XML as "interrupt_pin_routing" nodes.
* IRQs encoded in _CRS directly are represented as resources of type
"irq".
* Interrupt lines (i.e. INTx#) of PCI devices are represented as
resources of type "interrupt_pin". When the PCI routing table is
available, the corresponding interrupt line is identified and
represented as the "source" attribute of the resource node.
Due to the existence of vIOAPIC in ACRN VMs, the board inspector interprets
the \_PIC method with parameter 1 to inform the ACPI namespace that the
interrupt model should be in APIC mode.
v1 -> v2:
* Remove the msi_enable variable which is defined but never used.
Tracked-On: #6287
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
_STR is another device identification object defined in ACPI spec that
describes a device. This patch collects this string (when available) into
board XML as well.
Tracked-On: #6287
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
The warning, info and debug logging levels are intended to be used in the
following way.
* Warnings are used when users are expected to be aware of a certain
failure.
* Info messages are used to track parsing process and major internal
errors for development.
* Debug messages are used to collect verbose debug logs.
To align the current usage of logs to the above guidelines, this patch
adjusts the logging level of the following messages:
* DSDT/SSDT interpretation failures are now warnings, not information
* Failures of parsing deferred AML blocks are now information, not debug
messages
The default log level when running `cli.py` is adjusted to WARNING as well,
as INFO is primarily used for development. A new command line option
`loglevel` is added to adjust the log level per user needs.
v2 -> v3:
* Make address collisions in ACPI namespace as an info rather than a
warning.
Tracked-On: #6287
Signed-off-by: Junjie Mao <junjie.mao@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>
While running in a nested environment, such as qemu, parse the board
information should be allowed even it is not in a native environment.
Replace the error with warning message and does not exit the program.
Tracked-On: #6208
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Add the MSI-X capability structure nodes under <capability
id="MSI-X"> in board.xml.
Example:
<capability id="MSI-X">
<table_size>16</table_size>
<table_bir>1</table_bir>
<table_offset>0x1000000</table_offset>
<pba_bir>1</pba_bir>
<pba_offset>0x0</pba_offset>
</capability>
Fix the MSI <count> nodes when there is only one vector.
Tracked-On: #6235
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
This patch adds support to parse RTCT v2 using the refined board XML
schema. The major changes include:
- Add the RTCT v2 parser in the acpiparser module. The version of an RTCT
is detected automatically to choose the right parser.
- Extract software SRAM capabilities of caches into the board XML.
- Move the logic that determines the software SRAM base address for the
pre-launched VM to the static allocator of GPAs.
- Generate software SRAM related macros into misc_cfg.h when necessary.
Tracked-On: #6020
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This patch extracts information on devices and put them under the
`/acrn-config/devices` node in the board XML.
The generated XML looks like the following:
<devices>
<bus type="system">
<acpi_object>\_SB_</acpi_object>
<bus id="PNP0A08" type="pci" address="0x0" description="...">
<vendor>0x8086</vendor>
<identifier>0x591f</identifier>
<subsystem_vendor>0x1028</subsystem_vendor>
<subsystem_identifier>0x07a1</subsystem_identifier>
<class>0x060000</class>
<acpi_object>\_SB_.PCI0</acpi_object>
<resource type="bus_number" min="0x0" max="0x3e" len="0x3f"/>
<resource type="io_port" min="0x0" max="0xcf7" len="0xcf8"/>
<resource type="io_port" min="0xcf8" max="0xcf8" len="0x8"/>
<resource type="io_port" min="0xd00" max="0xffff" len="0xf300"/>
<resource type="memory" min="0x10000" max="0x1ffff" len="0x0"/>
<resource type="memory" min="0xa0000" max="0xbffff" len="0x20000"/>
<resource type="memory" min="0xc0000" max="0xc3fff" len="0x4000"/>
<resource type="memory" min="0xc4000" max="0xc7fff" len="0x4000"/>
...
<capability id="vendor_specific"/>
<device address="0x1"> ... </device>
...
<bus>
<bus>
<device> ... <device>
<devices>
The hierarchy of devices are based on the hierarchy of device objects in
the ACPI namespace (which is established by interpreting the ACPI DSDT and
SSDT tables). Typically most device objects are under the predefined
`_SB_` (i.e. System Bus) object under which an object representing the PCI
root complex (`\_SB_.PCI0` in the example above) can be found. The PCI
devices attached to bus 0 are listed as children of the PCI root complex
node.
For each bus or device, the board inspector tries best to parse the
information from both ACPI device objects and PCI configuration space to
extract the following:
- the model (via `_HID` object and PCI vendor ID, device ID and class code),
- assigned resources (via `_CRS` object and PCI BARs),
- capabilities (via the PCI capability list)
v1 -> v2:
- Fix references to undeclared modules or variables.
- Make the ACPI extractor advanced and not enabled by default.
- Extract the secondary I/O and memory-mapped I/O addresses of bridges.
Tracked-On: #5922
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This patch extracts information on mapping of available RAM and put them
under the `/acrn-config/memory` node in the board XML. Each range of
available RAM is represented by its start (host physical) address, end
address and size (in byte).
The following is an example of the generated XML.
<memory>
<range start="0x0000000000000000" end="0x0000000000057fff" size="360448"/>
<range start="0x0000000000059000" end="0x000000000009dfff" size="282624"/>
<range start="0x0000000000100000" end="0x00000000c9ff9fff"
size="3387924480"/>
<range start="0x00000000c9ffc000" end="0x00000000d984afff"
size="260370432"/>
<range start="0x00000000dbdff000" end="0x00000000dbdfffff" size="4096"/>
<range start="0x0000000100000000" end="0x000000041dffffff"
size="13388218368"/>
</memory>
Tracked-On: #5922
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This patch extracts information on cache topology and capabilities and put
them under the `/acrn-config/caches` node in the board XML in the following
manner.
<caches>
<cache level="1" id="0x0" type="1">
<cache_size>32768</cache_size>
<line_size>64</line_size>
<ways>8</ways>
<sets>64</sets>
<partitions>1</partitions>
<self_initializing>1</self_initializing>
<fully_associative>0</fully_associative>
<write_back_invalidate>0</write_back_invalidate>
<cache_inclusiveness>0</cache_inclusiveness>
<complex_cache_indexing>0</complex_cache_indexing>
<processors>
<processor>0x0</processor>
<processor>0x1</processor>
</processors>
</cache>
<cache level="1" id="0x0" type="2"> ... </cache>
<cache level="1" id="0x1" type="1"> ... </cache>
<cache level="1" id="0x1" type="2"> ... </cache>
...
<cache level="2" id="0x0" type="3"> ... </cache>
<cache level="2" id="0x1" type="3"> ... </cache>
...
<cache level="3" id="0x0" type="3"> ... </cache>
</caches>
Each cache block is represented by a separate `cache` node identified by
its level, cache ID and type (as reported by CPUID). More information, such
as the size, characteristics and capabilities, are attached as children of
the node.
The current implementation fetches cache information solely from the CPUID
leaf 4H. In the future more cache-related information, such as those in the
ACPI RTCT tables, will be appended here.
Tracked-On: #5922
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This patch extracts information on CPU topology and capability and put them
under the `/acrn-config/processors` node in the board XML.
The added information can be divided into two categories.
1. The topology of CPUs like the following. Each thread (which is a leaf
node in the topology) contains its addresses (i.e. CPU ID, APIC ID,
x2APIC ID) and model identifiers (i.e. family, model, stepping IDs, core
types and native model ID).
<die id="0">
<core id="0x0">
<thread id="0x0">
<cpu_id>0</cpu_id>
<apic_id>0x0</apic_id>
<x2apic_id>0x0</x2apic_id>
<family_id>0x6</family_id>
<model_id>0x9e</model_id>
<stepping_id>0x9</stepping_id>
<core_type></core_type>
<native_model_id></native_model_id>
</thread>
<thread id="0x1"> ... </thread>
</core>
<core id="0x1">
<thread id="0x2"> ... </thread>
<thread id="0x3"> ... </thread>
</core>
<core id="0x2">
<thread id="0x4"> ... </thread>
<thread id="0x5"> ... </thread>
</core>
<core id="0x3">
<thread id="0x6"> ... </thread>
<thread id="0x7"> ... </thread>
</core>
</die>
2. The CPU models identified by the quadruple (family_id, model_id,
core_type, native_model_id). Each model is described by its brandstring
and capabilities, both of which are fetched from CPUID leaves.
<model description="Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz">
<family_id>0x6</family_id>
<model_id>0x9e</model_id>
<core_type></core_type>
<native_model_id></native_model_id>
<capability id="sse3"/>
<capability id="pclmulqdq"/>
<capability id="dtes64"/>
<capability id="monitor"/>
...
</model>
Tracked-On: #5922
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This patch makes the `run.py` enumerate and invoke all extractors (whose
name should be `##-<name>.py` where `##` is a decimal number for ordering)
under the extractors/ directory. Only some helper subroutines are added in
this patch; the actual extractors will be added in the subsequent patches
in this series.
v1 -> v2:
- Allow an extractor to be classified as advanced by defining the variable
`advanced` to True. Advanced extractors are not enabled by default and
can be invoked by passing `--advanced` to the board inspector.
Tracked-On: #5922
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Kunhui-Li