From: Randy Dunlap <rdunlap@infradead.org>
To: Liju-clr Chen <liju-clr.chen@mediatek.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Richard Cochran <richardcochran@gmail.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Yingshiuan Pan <Yingshiuan.Pan@mediatek.com>,
Ze-yu Wang <Ze-yu.Wang@mediatek.com>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-trace-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-mediatek@lists.infradead.org,
Shawn Hsiao <shawn.hsiao@mediatek.com>,
PeiLun Suei <PeiLun.Suei@mediatek.com>,
Chi-shen Yeh <Chi-shen.Yeh@mediatek.com>,
Kevenny Hsieh <Kevenny.Hsieh@mediatek.com>
Subject: Re: [PATCH v12 02/24] docs: geniezone: Introduce GenieZone hypervisor
Date: Tue, 30 Jul 2024 07:13:54 -0700 [thread overview]
Message-ID: <190e49bb-88d2-49fe-a228-c379c33503c1@infradead.org> (raw)
In-Reply-To: <20240730082436.9151-3-liju-clr.chen@mediatek.com>
Hi--
On 7/30/24 1:24 AM, Liju-clr Chen wrote:
> From: Yingshiuan Pan <yingshiuan.pan@mediatek.com>
>
> GenieZone is MediaTek proprietary hypervisor solution, and it is running
> in EL2 stand alone as a type-I hypervisor. It is a pure EL2
> implementation which implies it does not rely any specific host VM, and
> this behavior improves GenieZone's security as it limits its interface.
>
> Signed-off-by: Yingshiuan Pan <yingshiuan.pan@mediatek.com>
> Co-developed-by: Yi-De Wu <yi-de.wu@mediatek.com>
> Signed-off-by: Yi-De Wu <yi-de.wu@mediatek.com>
> Signed-off-by: Liju Chen <liju-clr.chen@mediatek.com>
> ---
> Documentation/virt/geniezone/introduction.rst | 87 +++++++++++++++++++
> Documentation/virt/index.rst | 1 +
> MAINTAINERS | 6 ++
> 3 files changed, 94 insertions(+)
> create mode 100644 Documentation/virt/geniezone/introduction.rst
>
> diff --git a/Documentation/virt/geniezone/introduction.rst b/Documentation/virt/geniezone/introduction.rst
> new file mode 100644
> index 000000000000..f280476228b3
> --- /dev/null
> +++ b/Documentation/virt/geniezone/introduction.rst
> @@ -0,0 +1,87 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +======================
> +GenieZone Introduction
> +======================
> +
> +Overview
> +========
> +GenieZone hypervisor (gzvm) is a type-1 hypervisor that supports various virtual
> +machine types and provides security features such as TEE-like scenarios and
> +secure boot. It can create guest VMs for security use cases and has
> +virtualization capabilities for both platform and interrupt. Although the
> +hypervisor can be booted independently, it requires the assistance of GenieZone
> +hypervisor kernel driver(also named gzvm) to leverage the ability of Linux
driver (also
> +kernel for vCPU scheduling, memory management, inter-VM communication and virtio
> +backend support.
> +
> +Supported Architecture
> +======================
> +GenieZone now only supports MediaTek ARM64 SoC.
> +
> +Features
> +========
> +
> +- vCPU Management
> +
> + VM manager aims to provide vCPUs on the basis of time sharing on physical
> + CPUs. It requires Linux kernel in host VM for vCPU scheduling and VM power
> + management.
> +
> +- Memory Management
> +
> + Direct use of physical memory from VMs is forbidden and designed to be
> + dictated to the privilege models managed by GenieZone hypervisor for security
> + reason. With the help of gzvm module, the hypervisor would be able to manipulate
Is this change acceptable?:
With the help of the gzvm module, the hypervisor is able to manipulate
> + memory as objects.
> +
> +- Virtual Platform
> +
> + We manage to emulate a virtual mobile platform for guest OS running on guest
s/We manage to emulate/The gzvm hypervisor emulates/
or something like that...
> + VM. The platform supports various architecture-defined devices, such as
> + virtual arch timer, GIC, MMIO, PSCI, and exception watching...etc.
> +
> +- Inter-VM Communication
> +
> + Communication among guest VMs was provided mainly on RPC. More communication
is provided
> + mechanisms were to be provided in the future based on VirtIO-vsock.
are to be provided
or
will be provided
> +
> +- Device Virtualization
> +
> + The solution is provided using the well-known VirtIO. The gzvm module would
The gzvm module
> + redirect MMIO traps back to VMM where the virtual devices are mostly emulated.
redirects
> + Ioeventfd is implemented using eventfd for signaling host VM that some IO
> + events in guest VMs need to be processed.
> +
> +- Interrupt virtualization
> +
> + All Interrupts during some guest VMs running would be handled by GenieZone
interrupts are handled
> + hypervisor with the help of gzvm module, both virtual and physical ones.
> + In case there's no guest VM running out there, physical interrupts would be
no guest VM running, physical interrupts are
> + handled by host VM directly for performance reason. Irqfd is also implemented
> + using eventfd for accepting vIRQ requests in gzvm module.
> +
> +Platform architecture component
> +===============================
> +
> +- vm
> +
> + The vm component is responsible for setting up the capability and memory
> + management for the protected VMs. The capability is mainly about the lifecycle
> + control and boot context initialization. And the memory management is highly
> + integrated with ARM 2-stage translation tables to convert VA to IPA to PA
> + under proper security measures required by protected VMs.
> +
> +- vcpu
> +
> + The vcpu component is the core of virtualizing aarch64 physical CPU runnable,
The ending "runnable" doesn't seem to fit here - or I just can't parse that.
> + and it controls the vCPU lifecycle including creating, running and destroying.
> + With self-defined exit handler, the vm component would be able to act
the vm component is able to act
> + accordingly before terminated.
before termination.
or
before being terminated.
or
before exit.
> +
> +- vgic
> +
> + The vgic component exposes control interfaces to Linux kernel via irqchip, and
> + we intend to support all SPI, PPI, and SGI. When it comes to virtual
> + interrupts, the GenieZone hypervisor would write to list registers and trigger
hypervisor writes to list registers and triggers
> + vIRQ injection in guest VMs via GIC.
HTH.
--
~Randy
next prev parent reply other threads:[~2024-07-30 14:14 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-30 8:24 [PATCH v12 00/24] GenieZone hypervisor drivers Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 01/24] virt: geniezone: enable gzvm-ko in defconfig Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 02/24] docs: geniezone: Introduce GenieZone hypervisor Liju-clr Chen
2024-07-30 14:13 ` Randy Dunlap [this message]
2024-10-22 2:21 ` Liju-clr Chen (陳麗如)
2024-07-30 8:24 ` [PATCH v12 03/24] dt-bindings: hypervisor: Add MediaTek " Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 04/24] virt: geniezone: Add GenieZone hypervisor driver Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 05/24] virt: geniezone: Add vm support Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 06/24] virt: geniezone: Add set_user_memory_region for vm Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 07/24] virt: geniezone: Add vm capability check Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 08/24] virt: geniezone: Add vcpu support Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 09/24] virt: geniezone: Add irqchip support for virtual interrupt injection Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 10/24] virt: geniezone: Add irqfd support Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 11/24] virt: geniezone: Add ioeventfd support Liju-clr Chen
2024-07-31 8:57 ` Simon Horman
2024-07-30 8:24 ` [PATCH v12 12/24] virt: geniezone: Add memory region purpose for hypervisor Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 13/24] virt: geniezone: Add dtb config support Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 14/24] virt: geniezone: Optimize performance of protected VM memory Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 15/24] virt: geniezone: Add memory pin/unpin support Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 16/24] virt: geniezone: Add demand paging support Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 17/24] virt: geniezone: Add block-based " Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 18/24] virt: geniezone: Add memory relinquish support Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 19/24] virt: geniezone: Provide individual VM memory statistics within debugfs Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 20/24] virt: geniezone: Add tracing support for hyp call and vcpu exit_reason Liju-clr Chen
2024-08-07 20:02 ` Steven Rostedt
2024-07-30 8:24 ` [PATCH v12 21/24] virt: geniezone: Enable PTP for synchronizing time between host and guest VMs Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 22/24] virt: geniezone: Add support for virtual timer migration Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 23/24] virt: geniezone: Add support for guest VM CPU idle Liju-clr Chen
2024-07-30 8:24 ` [PATCH v12 24/24] virt: geniezone: Emulate IPI for guest VM Liju-clr Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=190e49bb-88d2-49fe-a228-c379c33503c1@infradead.org \
--to=rdunlap@infradead.org \
--cc=Chi-shen.Yeh@mediatek.com \
--cc=Kevenny.Hsieh@mediatek.com \
--cc=PeiLun.Suei@mediatek.com \
--cc=Yingshiuan.Pan@mediatek.com \
--cc=Ze-yu.Wang@mediatek.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=catalin.marinas@arm.com \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=liju-clr.chen@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=matthias.bgg@gmail.com \
--cc=mhiramat@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=richardcochran@gmail.com \
--cc=robh@kernel.org \
--cc=rostedt@goodmis.org \
--cc=shawn.hsiao@mediatek.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).