Since the PR #6787 has landed, we need to remove the uuid parameter
"-U" of "acrn-dm" and replace UUID with vm name to identify a VM
in document.
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
- Replace SOS or Service OS with Service VM
- Replace UOS or User OS with User VM
- Clean up some of the grammar
Signed-off-by: Amy Reyes <amy.reyes@intel.com>
* General scan for misspellings, "smart quotes", and formatting errors
missed during regular review. Also removed used of "please".
* Fix old XML examples that had desc="..." comments. These comments were
moved to to xsd files instead of being in the XML files themselves.
Signed-off-by: David B. Kinder <david.b.kinder@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>
After grand update of all titles to use title-case, we found a few that
needed a manual tweak.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
While we hoped to make the headings consistent over time while doing
other edits, we should instead just make the squirrels happy and do them
all at once or they'll likely never be made consistent.
A python script was used to find the headings, and then a call to
https://pypi.org/project/titlecase to transform the title. A visual
inspection was used to tweak a few unexpected resulting titles.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Did a partial run of ACRN documents through Acrolinx to catch additional
spelling and grammar fixes missed during regular reviews.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Also clear Linux is no longer supported either as SOS or post-launched VM kernel.
- When it mentions clear Linux, mostly replaced by Ubuntu.
- remove all contents re/lated to "UEFI boot".
- remove the term de-privilege mode, and direct mode as well.
Tracked-On: #5197
Signed-off-by: Zide Chen <zide.chen@intel.com>
Fix links in documentation that have moved (e.g.,
clearlinux.org/documentation moved to docs.01.org/clearlinux/latest).
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
1. add guest secure boot with OVMF.
2. delete obsolete content.
3. SOS -> Service VM and UOS -> User VM.
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
As reported in PR #3959, doc build errors were being masked by a script
error. This PR fixes a chunk of them.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Changing the folder structure will cause too many broken links for
external references (from other sites). So, let's put the content back
where it was before the reorg, and instead use the new persona-based
navigation to point to documents in the original locations.
Also, introduce redirects for some documents that no longer exits.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Take the existing ACRN technical documentation and reorganize its
presentation to be persona and use-case based, in preparation for adding
new scenario/use-case based architecture introduction and getting
started documents.
Introduce a more graphical home page and theme color tweaks.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Original design is to map trusty's memory to 512G~513G, but GR-MRB platform
does not support memory mapping bigger than 512G. So final implementation
is mapping trusty's memory to 511G~512G.
This patch update the documentation with latest implementation.
Tracked-On: #2742
Signed-off-by: Qi Yadong <yadong.qi@intel.com>
Proper use of the Clear Linux name is with a noun, specifically "OS".
Also fixed some grammar edits along the way.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Reorganize the high-level design docs to align with a work-in-progress
HLD document. Migrate previous web content (and images) into the new
organization.
From here we'll continue inclusion of new design chapters as they're
reviewed and edited.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
