The EnablementType is now obsolete and config items having this type have
been updated to use the Boolean type. However, the upgrader is not changed
accordingly and it still converts "y" or "n" of certain config items to
"Enable" or "Disable".
This patch drops the EnablementType in the schema and updates the upgrader
to respect the latest definitions.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
The default error messages provided by the ajv validation library read like
this:
* must have required property MEMORY.STACK_SIZE
* must match pattern "<a regular expression>"
Such messages may look confusing as users are not supposed to understand
the internal naming of the config items or the regular expressions used to
validate strings.
This patch enables the XML schema to include 'acrn:errormsg' annotations
which is a dictionary from error types to customized error messages. This
mechanism is used to show more user-friendly messages upon common errors
such as missing or invalid data in required config item.
Tracked-On: #6691
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This patch validates the structure of the XML files given before they are
further used by the rest of the configurator. With this validation process,
the configurator confirms the XML files are well-structured and can thus
access certain nodes and contents without checking their existence or data
types.
Upon validation failure, an alert will pop up informing the user that the
given XML file is ill-formed. No further details are given as of now
because we assume users should not care about the internal structure of
those files.
Tracked-On: #6691
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
The configurator today shows "Please Input" as the placeholder of input
widgets, which is far from informative.
This patch specifies element or type specific placeholders in the XML
schema by reusing the `acrn:widget-options` annotation mechanism. For
manually-designed widgets such as ivshmem or vUART the placeholders are
added in the corresponding vue directly.
Tracked-On: #6691
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Copy scenrio.json to build directory, and modify the temporary file
to avoid pollution of hypervisor repo.
Tracked-On: #7459
Signed-off-by: Yuanyuan Zhao <yuanyuan.zhao@linux.intel.com>
1. add Vue devtools support
2. update project dependencies
3. refactor configurator source code tree for private library hook
4. fix build issue
5. dynamic load scenario JSON schema(fix cache issue)
6. add vjsf 1.12.2 (latest) for private package dependencies
7. remove vjsf unnecessary files
8. use private vjsf as configurator dependencies
9. Add custom IVSHMEM_REGION widget
10. add a script to populate default values
11. get default values before export scenario xml
12. specify widgets in XML schema
13. add missing vjsf license file
14. populate default values to empty nodes
15. when user clicks save button, update formData with each field default value
16. fix when the user clicks the save button will collapse configFom
17. add success message for saving scenario XML
vue-json-schema-form 1.12.2 (latest)link: b30ea7c2d6/packages/lib
Tracked-On: #6691
Signed-off-by: Weiyi Feng <weiyix.feng@intel.com>
During conversion from xml to scenario.json, elements with "maxOccurs"
property is processed as json array, and (most) properties of that elements
goes to the json array. However the "enum" property should belong to the
array item, not the array itself.
Tracked-On: #7421
Signed-off-by: Yifan Liu <yifan1.liu@intel.com>
1. add virtio gpu logic in upgrader.py script.
2. fix the upgraded virtio elements issue.
3. add the logic to remove the element with empty value in xml file
to use the default value.
Tracked-On: #7301
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Do not copy the 'board' and 'scenario' in <acrn-config> to the new xml.
Tracked-On: #7345
Signed-off-by: Conghui <conghui.chen@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
According to DX recommendations, this patch adds a Boolean item to each
vCPU which allows users to specify the vCPUs intended for
real-time-critical tasks. This information will be used to organize other
widgets (CAT-related ones for now) in the configurator to tell apart
real-time ones from the others for better clarity.
All vCPUs are by default not real-time-critical, except those in the RT VMs
which are.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This patch adds the assertion (in XSD) that validates if all explicitly
specified vBDF (including those for virtual UART controllers and IVSHMEM
interfaces) are unique.
Tracked-On: #7330
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Different from other nodes which have static default values, the virtual
BDF nodes of virtual UART endpoints or IVSHMEM interfaces have a set of
default values and should be used with uniqueness guaranteed. The existing
default value mechanism in XSD does not include support for this.
This patch adds two more ACRN-specific annotations, namely `acrn:defaults`
and `acrn:unique-among`, that have the following semantics.
- `acrn:defaults` is a Python expression that evaluates to an iterable.
- `acrn:unique-among` is an xpath that specifies the nodes. Each node
within the select ones shall have a value unique among them. The xpath
is evaluated with the variable `parent` defined as the parent node
under which the vBDF node is to be appended.
Tracked-On: #7330
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
We have redesigned Virtio devices, so this patch updates
the upgrader.py script for them.
Tracked-On: #6690
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Many of the license and Intel copyright headers include the "All rights
reserved" string. It is not relevant in the context of the BSD-3-Clause
license that the code is released under. This patch removes those strings
throughout the code (hypervisor, devicemodel and misc).
Tracked-On: #7254
Signed-off-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
remove board and scenario attributes dependency for new configuration.
To do:
will remove board and scenario attributes in all scenario XML files
and update the upgrader.py after the new configuration works.
Tracked-On: #6690
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
In the old days SERVICE_VM was also an acceptible VM type. It is now converted
to the load_order, with the vm_type field replaced by STANDARD_VM. This patch
adds this conversion logic into the upgrader.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Since PR #6943 has landed, the `CONFIG_IOMMU_BUS_NUM` has been renamed
to `ACFG_MAX_PCI_BUS_NUM`, this patch removes the obsolete code about
`CONFIG_IOMMU_BUS_NUM`.
v1-->v2:
Update the upgrader.py to add a description of this obsoleted item.
Tracked-On: #6942
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
The next-generation ACRN configurator will embed a Python interpreter built
in WebAssembly (WASM) for executing Python scripts for manipulating
scenario schemas and validating user data. It is quite tedious to
separately import multiple modules there due to the restriction of that
Python environment. The recommended approach is to package those
modules (e.g. as a *.wic file) so that all modules can be imported in one
shot.
This patch adds the files needed to package the scripts. The package is
solely used for the configurator to import and not intended to be used by
end users for any purpose.
v1 -> v2:
* Fix the license header of __init__.py
* Move patterns of ignored files to the top-level .gitignore
Tracked-On: #6691
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Reviewed-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
In order for more effective and specific error reporting, this patch
enhanced the XML assertion validation mechanism by:
- Enhancing the elementpath library at runtime to capture of quantified
variables that causes an assertion to fail, which can be used as a
counter example of the rule.
- Allowing error messages (as xs:documentation in the XML schema)
embedding XPath (up to 2.0) which will be evaluated against the counter
example to provide more specific information about the error.
- Adding to assertions a mandatory attribute which specifies the context
node(s) of an error using XPath. These nodes can be further used in the
configurator to attach the errors to the widgets where users can fix
them.
v1 -> v2:
* Logging the validation errors according to their defined severity
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Splitting the definitions of a post-launched VM into two files, namely the
scenario XML and launch XML, introduces duplicated field in both files and
leads to a high probability of having inconsistencies between them (see
issue #7156 as an example). Further more, this split has also adds much
complexity to the configurator which has to either hide some of the items
from user interfaces or synchronize different fields upon changes.
The advantage of the split, however, is not widely adopted. Having a
separate XML capturing the VM definition tweakable in the service VM at
runtime seems to give users more flexibility to redefine a VM without
recompiling the hypervisor. But that is not a common practice in the
industry segment; instead it is preferred to have a static scenario
definition to make sure that all resources are allocated carefully in a
fixed manner in order for better determinism.
As a result, this patch merges the fields in launch XMLs into the schema of
scenario XMLs. Some fields are post-launched VM specific and thus added,
while the others have similar items in scenario XMLs today.
The launch script generator is also updated accordingly to generate launch
scripts from the new scenario XMLs (which now contain the same amount of
information as previous launch XMLs).
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This patch adds the following annotations to the config items defined in
the schema of scenario XMLs:
- acrn:title, which defines the human-readable label of the corresponding
widgets in the configurator.
- acrn:views, which controls in which view(s) this item shows in the
configurator.
- acrn:applicable-vms, which specifies the kinds of VMs (pre-launched,
post-launched and/or service VM) this item applies to. An item not
applicable to a certain type of VM will not be shown in the
configurator, and will trigger validation error if that item exists for
a VM of that specific type.
v1 -> v2:
* Preserve the CPU affinity settings for service VMs. This will be needed
later when we want to restrict the available CPUs the service VM can use at
runtime (but not at initialization time).
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
A shared memory region can be provided either by the hypervisor or by the
device model. Before recent schema changes this is telled by the "hv:/" or
"dm:/" prefix.
This patch adds another node under an IVSHMEM region to represent the
provider, following the practice that information in the old-school
encodings is split and put as separate XML nodes.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
As is recommended by UX/DX reviews, the per-VM console virtual UART is now
limited to the following choices:
- Disabled
- a COM port from COM1 to COM4
- PCI based
This patch converts the schema of scenario XMLs to integrate this
recommendation and add logic in the scenario upgrader to migrate data from
old scenario XMLs.
v1 -> v2:
* Update the static allocators and C source transformers according to the
new console vUART config item.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Instead of using a Boolean variable indicating whether a build is for debug
or release, it is more intuitive to specify the build types as "debug" or
"release".
This patch converts the config item RELEASE to BUILD_TYPE which takes
"debug" or "release" as of now.
The generated header and makefile still uses RELEASE, and the command line
option RELEASE=<y or n> is also preserved.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
With a bunch of dramatic improvement to the schema of scenario XML
recently, it is now non-trivial for users of previous releases to migrate
their scenario definitions to the next-gen schema, which will be a
major obstacle when upgrading to the next ACRN release.
In order to ease the upgrade of scenario XML, this patch introduces a
script that takes a scenario XML of previous releases and generates a new
one which satisfies the latest schema. The major data that can be migrated
include:
- Virtual UART and shared memory configurations
- VM types, load_order and guest flags
Other data are preserved as long as they are still needed according to the
schema. The script to print a list that summarizes the data that are
unintendedly discarded during the upgrade, so that users can double check
the results and edit the generated scenario using the configurator.
The upgrader share the same command-line interface of the default value
populator and scenario validator.
More upgrading logic will be added at the same time the schema is changed.
v1 -> v2:
* The upgrader now pretty-prints the upgraded XML.
* Apply the upgrader to the current scenario XMLs in the repo. The
ordering of nodes are adjusted to align with the schema, but no
essential changes are made.
* Set the log level to INFO.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
We plan to add the following attributes to element definitions in the XML
schema:
- acrn:applicable-vms, which specify if an element applies to a
pre-launched VM, the service VM or a post-launched VM
- acrn:views, which specify if an element shall appear in the basic or
advanced tab in the configurator.
In order to reduce the attributes above to existing XML technologies, we
need to create new complex types that lists all config items that applies
to a pre-launched VM, the service VM or a post-launched VM, or that should
be shown in the basic or advanced view. Such types can then be used to
replace the original, all-in-one type during validation or configurator
rendering.
When unspecified, an element always applies under all possible
circumstances.
To realize this slicing mechanism, this patch adds a generic class
implementing the common part of slicing XML schema types and two
specific-purpose slicers according to the applicable VMs or views
attributes.
v2 -> v3:
* Update configdoc.xsl to recognize types in xs:alternative nodes.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Today the scripts that populate default values and validate scenarios have
different command-line interfaces: the former requires an XML schema as
input (which is cumbersome in most cases), while the latter always infer
where the XML schema is (which is inflexible).
This patch unifies the command line options of those scripts as follows:
- The scenario XML is always a required positional argument.
- The output file path (if any) is an optional positional argument.
- The schema XML file is an optional long option. When not specified, the
scripts will always use the one under the misc/config_tools/schema
directory.
Also, this patch makes the validator.py executable, as is done to other
executable scripts in the repo.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
There is an increasing demand of composing different operations around XML
schemas and/or data in different ways for different purpose. Today we
already have:
- Validate XML data, which takes XML schemas and data (board and
scenario) as inputs.
- Fill in missing nodes in XML data with default values, which takes XML
schema and data (scenario only) as inputs.
In the near future we'll extend the operations around XMLs by introducing
XML schema preprocessing and XML data upgrading, adding more possibilities
to construct a larger operation by composing smaller ones.
In order for minimized code repetition and easier composition, this patch
introduces an infrasturcture that abstracts each operation as a pipeline
stage. Each stage defines its own inputs and outputs and can be composed
sequentially as a larger, single operation.
The existing operations listed above, along with XML file loaders, are then
refactored to provide pipeline stages. The main methods are also refined to
complete their tasks by constructing and invoking pipelines.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Today the default value populator will always create a node if it is
required by the schema but not provided in the given XML file. This could
hide issues in a given scenario XML if a node does not have default
values (i.e. require user's inputs) but accepts empty text.
This patch avoids the creation of nodes without a default value so that, at
validation stage, missing of essential data is always reported.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
The "xs:alternative" nodes in XML schema enables specifying different types
for the same node according to the contents of that node. A typical usage
of this construct in the schema of scenario XMLs is to specify different
types for a `vm` node depending on whether it is a pre-launched,
post-launched or service VMs, so that each VM contains only configurations
supported in that kind of VM.
This patch adds support of xs:alternative nodes to the schema transformer
so that default values can be populated appropriately after we add
xs:alternative nodes to the schema.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Today the script default_populator.py fills in default values by visiting
an XML schema and an XML tree simultaneously and add a node to the latter
whenever one satisfying the schema does not exist. This visiting logic is
not only useful for filling in default values, but also for upgrading
XMLs to new schemas.
This patch abstracts the flow of the visiting above as a separate class,
just like tree visitors or transformers. The current default value
populator is then refactored to extend that class by inheritance.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This patch includes:
1.add load_order(PRE_LAUNCHED_VM/SERVICE_VM/POST_LAUNCHED_VM) parameter
2.change vm_type parameter to values as RTVM, STANDARD_VM, TEE, REE
TEE and REE are hide in UI.
3.deduce vm severity in vm_configuration from vm_type and load_order
This patch not includes:
change for scenario_config and functions called by scenario_config about checking
v2->v3:
*Refine template load_order
v1->v2:
*Change variable name from vm_type to load_order
*Change LoadOptionType to LoadOrderType
*Change VMOptionsType to VMType
*Add TEE_VM/REE_VM description
*Refine acrn:is-pre-launched-vm
Tracked-On: #6690
Signed-off-by: hangliu1 <hang1.liu@linux.intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Today the XML validation logic is embedded in scenario_cfg_gen.py which is
highly entangled with the Python-internal representation of
configurations. Such representation is used by the current configurator,
but will soon be obsolete when the new configurator is introduced.
In order to avoid unnecessary work on this internal representation when we
refine the schema of scenario XML files, this patch separates the
validation logic into a new script which can either be used from the
command line or imported in other Python-based applications. At build time
this script will be used instead to validate the XML files given by users.
This change makes it easier to refine the current configuration items for
better developer experience.
Migration of existing checks in scenario_cfg_gen.py to XML schema will be
done by a following series.
v2 -> v3:
* Keep Invoking asl_gen.py to generate vACPI tables for pre-launched VMs.
v1 -> v2:
* Remove "all rights reserved" from the license header
* Upgrade the severity of the message indicating lack of xmlschema as
error according to our latest definitions of log severities, as
validation violations could indicate build time or boot time failures.
Tracked-On: #6690
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
1. remove the board_private tag in the schema and all existing scenario XML files,
and remove the related value check about board_private.rootfs and bootargs.
2. merge board_private.rootfs and board_private.bootargs to os_config.bootargs.
and no change to the related contents of the .c/.h files except the order of
define SERVICE_VM_ROOTFS.
3. update the schema to make os_config.bootargs configurable for service VM in UI.
Tracked-On: #6690
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
1. remove LOG_DESTINATION in the related python code, schema and
all existing scenario XML files.
2. for MEM_LOGLEVEL, NPK_LOGLEVEL and CONSOLE_LOGLEVEL,
update the loglevel range to [0, 5] from [0, 6].
Tracked-On: #6934
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
Because it is not configurable, config tool might not need to
define DM_OWNED_GUEST_FLAG_MASK. So we remove it in tool.
Tracked-On: #6366
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
1. remove CONFIG_KATA_VM, CONFIG_MAX_KATA_VM_NUM and KATA_VM
related code.
2. remove KATA_VM in scenario xml files.
3. remove KATA vm type in UI.
4. remove UUID DB.
5. remove uuid in the launch script generation logic.
6. use vmname to identify a vm. (eg: <name>ACRN_SOS_VM</name>)
add the check logic to ensure vm name is a must-set item, not duplicated,
and the string length is [1-15] and the whitespace is not allowed.
7. enlarge the max VM num to 32.
Tracked-On: #6685
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
1. ensure cpu affinity in launch xml is subset of its scenario settings.
2. cpu_affinity is a must have parameter for acrn_dm, if the user did not provide cpu affinity in launch xml, load it from scenario settings.
Tracked-On: #6724
Signed-off-by: Weiyi Feng <weiyix.feng@intel.com>
Rename SOS_VM type to SERVICE_VM
rename UOS to User VM in XML description
rename uos_thread_pid to user_vm_thread_pid
rename devname_uos to devname_user_vm
rename uosid to user_vmid
rename UOS_ACK to USER_VM_ACK
rename SOS_VM_CONFIG_CPU_AFFINITY to SERVICE_VM_CONFIG_CPU_AFFINITY
rename SOS_COM to SERVICE_VM_COM
rename SOS_UART1_VALID_NUM" to SERVICE_VM_UART1_VALID_NUM
rename SOS_BOOTARGS_DIFF to SERVICE_VM_BOOTARGS_DIFF
rename uos to user_vm in launch script and xml
Tracked-On: #6744
Signed-off-by: Liu Long <long.liu@linux.intel.com>
Reviewed-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
Rename SOS_VM_NUM to SERVICE_VM_NUM.
rename SOS_SOCKET_PORT to SERVICE_VM_SOCKET_PORT.
rename PROCESS_RUN_IN_SOS to PROCESS_RUN_IN_SERVICE_VM.
rename PCI_DEV_TYPE_SOSEMUL to PCI_DEV_TYPE_SERVICE_VM_EMUL.
rename SHUTDOWN_REQ_FROM_SOS to SHUTDOWN_REQ_FROM_SERVICE_VM.
rename PROCESS_RUN_IN_SOS to PROCESS_RUN_IN_SERVICE_VM.
rename SHUTDOWN_REQ_FROM_UOS to SHUTDOWN_REQ_FROM_USER_VM.
rename UOS_SOCKET_PORT to USER_VM_SOCKET_PORT.
rename SOS_CONSOLE to SERVICE_VM_OS_CONSOLE.
rename SOS_LCS_SOCK to SERVICE_VM_LCS_SOCK.
rename SOS_VM_BOOTARGS to SERVICE_VM_OS_BOOTARGS.
rename SOS_ROOTFS to SERVICE_VM_ROOTFS.
rename SOS_IDLE to SERVICE_VM_IDLE.
rename SEVERITY_SOS to SEVERITY_SERVICE_VM.
rename SOS_VM_UUID to SERVICE_VM_UUID.
rename SOS_REQ to SERVICE_VM_REQ.
rename RTCT_NATIVE_FILE_PATH_IN_SOS to RTCT_NATIVE_FILE_PATH_IN_SERVICE_VM.
rename CBC_REQ_T_UOS_ACTIVE to CBC_REQ_T_USER_VM_ACTIVE.
rename CBC_REQ_T_UOS_INACTIVE to CBC_REQ_T_USER_VM_INACTIV.
rename uos_active to user_vm_active.
Tracked-On: #6744
Signed-off-by: Liu Long <long.liu@linux.intel.com>
Reviewed-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
Add the VCAT_ENABLED element to RDTType so that user can enable/disable vCAT globally
Add the GUEST_FLAG_VCAT_ENABLED guest flag to enable/disable vCAT per-VM.
Currently we have the following per-VM clos element in scenario file for RDT use:
<clos>
<vcpu_clos>0</vcpu_clos>
<vcpu_clos>0</vcpu_clos>
</clos>
When the GUEST_FLAG_VCAT_ENABLED guest flag is not specified, clos is for RDT use,
vcpu_clos is per-CPU and it configures each CPU in VMs to a desired CLOS ID.
When the GUEST_FLAG_VCAT_ENABLED guest flag is specified, vCAT is enabled for this VM,
clos is for vCAT use, vcpu_clos is not per-CPU anymore in this case, just a list of
physical CLOSIDs (minimum 2) that are assigned to VMs for vCAT use. Each vcpu_clos
will be mapped to a virtual CLOSID, the first vcpu_clos is mapped to virtual CLOSID
0 and the second is mapped to virtual CLOSID 1, etc
Add xs:assert to prevent any problems with invalid configuration data for vCAT:
If any GUEST_FLAG_VCAT_ENABLED guest flag is specified, both RDT_ENABLED and VCAT_ENABLED
must be 'y'
If VCAT_ENABLED is 'y', RDT_ENABLED must be 'y' and CDP_ENABLED must be 'n'
For a vCAT VM, vcpu_clos cannot be set to CLOSID 0, CLOSID 0 is reserved to be used by hypervisor
For a vCAT VM, number of clos/vcpu_clos elements must be greater than 1
For a vCAT VM, each clos/vcpu_clos must be less than L2/L3 COS_MAX
For a vCAT VM, its clos/vcpu_clos elements cannot contain duplicate values
There should not be any CLOS IDs overlap between a vCAT VM and any other VMs
Tracked-On: #5917
Signed-off-by: dongshen <dongsheng.x.zhang@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
