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>
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>
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>
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>
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>