Updates to the Getting Started Guide:
* Update title to simply be "Getting Started Guide"
* Simplify and remove instructions that are redundant
* Add a note explaining the difference between 'nuc11tnbi5' and
'nuc11tnhi5'
Tracked-On: #6225
Signed-off-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
Update the ACRN documentation with regards to the supported HW:
* Remove outdated reference to Apollo Lake and Kaby Lake
* Re-order HW platforms in "Supported HW" to be consistent throughout
the document
* Use the '|copy|' and '|trade|' replacements
* Update the recommendation for creating nnon-existant $(BOARD).xml
Tracked-On: #6227
Signed-off-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
1. Update the rt_industry_ubuntu GSG file from WHL Maxtang to NUC11TNHi5.
2. Update the ACRN-hypervisor branch and ACRN-Kernel version to release_2.5.
3. Update the BIOS setting for NUC11TNHi5.
4. Update the rt-ind-ubun-hw-1.png and rt-ind-ubun-hw-2.png images for NUC11TNHi5;
And add the native-ubuntu-on-NVME-3.png and native-ubuntu-on-SATA-3.png pictures.
5. Update the PCI device IDs and busses in /usr/share/acrn/launch_hard_rt_vm.sh
for this new platform.
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
Update the "Enable ACRN Over QEMU/KVM" tutorial:
* Remove the steps explaining how to add the Virtio blk driver
to the Service VM kernel. It is now part of the default
configuration
* Add a note to make it more obvious that the tutorial assumes
that the compilation of ACRN and its kernel is done *inside*
the QEMU VM that will serve as the Service VM for ACRN
Signed-off-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
Update the content about getting board xml from native
enviroment in acrn_configuration_tool.rst and README.
Tracked-On: #6134
Signed-off-by: Kunhui Li <kunhuix.li@intel.com>
Replace rdstc() and get_tsc_khz() with their architectural agnostic
counterparts cpu_ticks() and cpu_tickrate().
Tracked-On: #5920
Signed-off-by: Yi Liang <yi.liang@intel.com>
Seperate options with simple types with a heading so they don't get
hidden under the previous options that are part of a complex type.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
get_ept_entry() actually returns the EPTP of a VM. So rename it to
get_eptp() for readability.
Tracked-On: #5923
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Add hugepages/hugepagesz parameters description in generic kernel
parameters because we remove the “hugepage/hugepagesz” setting
in HV code in v2.5 and the only user interface to this parameter
is to modify the two parameter in grub.
Tracked-On: #5815
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
We missed a section during our last update to the QEMU tutorial
that references which version (tag) of ACRN to use.
Tracked-On: #5928
Signed-off-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
Add a number of steps and details that were not called
out in the "Getting Started Guide for ACRN Hybrid Mode". Those
are not obvious to the first-time or novice user so the user
guide was hard to follow and confusing. At a high-level:
* How to build Zephyr
* How to install ACRN
* How to install the ACRN kernel
The hybrid scenario overview diagram has been updated too.
Tracked-On: #5992
Signed-off-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
x86/timer.[ch] was moved to the common directory largely unchanged.
x86 specific code now resides in x86/tsc_deadline_timer.c and its
interface was defined in hw/hw_timer.h. The interface defines two
functions: init_hw_timer() and set_hw_timeout() that provides HW
specific initialization and timer interrupt source.
Other than these two functions, the timer module is largely arch
agnostic.
Tracked-On: #5920
Signed-off-by: Rong Liu <rong2.liu@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Generalize and split basic cpu cycle/tick routines from x86/timer:
- Instead of rdstc(), use cpu_ticks() in generic code.
- Instead of get_tsc_khz(), use cpu_tickrate() in generic code.
- Include "common/ticks.h" instead of "x86/timer.h" in generic code.
- CYCLES_PER_MS is renamed to TICKS_PER_MS.
The x86 specific API rdstc() and get_tsc_khz(), as well as TSC_PER_MS
are still available in arch/x86/tsc.h but only for x86 specific usage.
Tracked-On: #5920
Signed-off-by: Rong Liu <rong2.liu@intel.com>
Signed-off-by: Yi Liang <yi.liang@intel.com>
The current permission-checking and dispatching mechanism of hypercalls is
not unified because:
1. Some hypercalls require the exact vCPU initiating the call, while the
others only need to know the VM.
2. Different hypercalls have different permission requirements: the
trusty-related ones are enabled by a guest flag, while the others
require the initiating VM to be the Service OS.
Without a unified logic it could be hard to scale when more kinds of
hypercalls are added later.
The objectives of this patch are as follows.
1. All hypercalls have the same prototype and are dispatched by a unified
logic.
2. Permissions are checked by a unified logic without consulting the
hypercall ID.
To achieve the first objective, this patch modifies the type of the first
parameter of hcall_* functions (which are the callbacks implementing the
hypercalls) from `struct acrn_vm *` to `struct acrn_vcpu *`. The
doxygen-style documentations are updated accordingly.
To achieve the second objective, this patch adds to `struct hc_dispatch` a
`permission_flags` field which specifies the guest flags that must ALL be
set for a VM to be able to invoke the hypercall. The default value (which
is 0UL) indicates that this hypercall is for SOS only. Currently only the
`permission_flag` of trusty-related hypercalls have the non-zero value
GUEST_FLAG_SECURE_WORLD_ENABLED.
With `permission_flag`, the permission checking logic of hypercalls is
unified as follows.
1. General checks
i. If the VM is neither SOS nor having any guest flag that allows
certain hypercalls, it gets #UD upon executing the `vmcall`
instruction.
ii. If the VM is allowed to execute the `vmcall` instruction, but
attempts to execute it in ring 1, 2 or 3, the VM gets #GP(0).
2. Hypercall-specific checks
i. If the hypercall is for SOS (i.e. `permission_flag` is 0), the
initiating VM must be SOS and the specified target VM cannot be a
pre-launched VM. Otherwise the hypercall returns -EINVAL without
further actions.
ii. If the hypercall requires certain guest flags, the initiating VM
must have all the required flags. Otherwise the hypercall returns
-EINVAL without further actions.
iii. A hypercall with an unknown hypercall ID makes the hypercall
returns -EINVAL without further actions.
The logic above is different from the current implementation in the
following aspects.
1. A pre-launched VM now gets #UD (rather than #GP(0)) when it attempts
to execute `vmcall` in ring 1, 2 or 3.
2. A pre-launched VM now gets #UD (rather than the return value -EPERM)
when it attempts to execute a trusty hypercall in ring 0.
3. The SOS now gets the return value -EINVAL (rather than -EPERM) when it
attempts to invoke a trusty hypercall.
4. A post-launched VM with trusty support now gets the return value
-EINVAL (rather than #UD) when it attempts to invoke a non-trusty
hypercall or an invalid hypercall.
v1 -> v2:
- Update documentation that describe hypercall behavior.
- Fix Doxygen warnings
Tracked-On: #5924
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
1. Add whitespace in the string "ubuntu18.04";
2. Update the Kernel version;
3. Update ACRN qemu HV tag format and add a note.
Tracked-On: #5928
Signed-off-by: Kunhui Li <kunhuix.li@intel.com>
Instead of "#include <x86/foo.h>", use "#include <asm/foo.h>".
In other words, we are adopting the same practice in Linux kernel.
Tracked-On: #5920
Signed-off-by: Liang Yi <yi.liang@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
clang-format is now used as part of the config tools creating c files
based on the XML configuration
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Add a note to the "Device Model Parameters" document to emphasize
the need to use the '--windows' parameter to use Windows-as-a-Guest
(WaaG), else Windows will not recognize the virtual disk it has
been assigned.
Tracked-On: #5962
Signed-off-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
Update known-issues pattern for PDF processing to also work with updated
xelatex tools from Ubuntu 20.04
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
PRs #5945 and #5949 introduced fixes to the doc building process to
support PDF generation of the documentation set. This PR refines the
doc build process, cleaning up the Makefile, adding display of tool
version information, and updates the doc building documentation to
include additional dependencies needed for building the PDF and
instructions for how to build the PDF. The latexpdf make target is
provided to just run the latex and PDF producing process that depends on
the HTML artifacts from a make html run. A new make pdf target is
provided that combines the two steps into one.
A new know-issues pattern file is added that verifies the expected
output from the latexpdf process is returned, as it can't be completely
eliminated without losing potential error messages that need to be
resolved.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Update missing captions on figures to remove remaining broken references
during latexpdf building. Also, require doing a "make html" before
doing a "make latexpdf" to build all the artifacts needed for running
the latexpdf build. (We might change that later if needed.)
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
This patch tweaks the settings in doc/conf.py to allow formatting the
documentation to a PDF file by Sphinx. The changes include:
- Use `xelatex` rather than the default `pdflatex` as the LaTeX engine, as
`pdflatex` is not that good at formatting non-ascii characters out of
the box.
- Use DejaVu fonts (which are available in common Linux distributions) in
the generated PDF.
- Restrict the depths of the table of contents to 3.
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Make the description of the "Logial Partitioning" scenario more
generic than what is shown on the figure. This also helps as the
current examples of that scenario in the code base do not use
Safety or RTVM at the moment (as shown on the picture).
Tracked-On: #5903
Signed-off-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
remove UOS_RAM_SIZE and SOS_RAM_SIZE in scenario config since these
two config elements are useless.
Tracked-On: #5927
Signed-off-by: Shuang Zheng <shuang.zheng@intel.com>
Reviewed-by: Victor Sun <victor.sun@intel.com>
