[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZVs760ggqT-erCji@archie.me>
Date: Mon, 20 Nov 2023 17:58:51 +0700
From: Bagas Sanjaya <bagasdotme@...il.com>
To: Yi-De Wu <yi-de.wu@...iatek.com>,
Yingshiuan Pan <yingshiuan.pan@...iatek.com>,
Ze-Yu Wang <ze-yu.wang@...iatek.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Jonathan Corbet <corbet@....net>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>
Cc: Arnd Bergmann <arnd@...db.de>, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org,
David Bradil <dbrazdil@...gle.com>,
Trilok Soni <quic_tsoni@...cinc.com>,
Jade Shih <jades.shih@...iatek.com>,
Ivan Tseng <ivan.tseng@...iatek.com>,
My Chuang <my.chuang@...iatek.com>,
Shawn Hsiao <shawn.hsiao@...iatek.com>,
PeiLun Suei <peilun.suei@...iatek.com>,
Liju Chen <liju-clr.chen@...iatek.com>,
Willix Yeh <chi-shen.yeh@...iatek.com>,
Kevenny Hsieh <kevenny.hsieh@...iatek.com>
Subject: Re: [PATCH v7 01/16] docs: geniezone: Introduce GenieZone hypervisor
On Thu, Nov 16, 2023 at 11:27:41PM +0800, Yi-De Wu wrote:
> diff --git a/Documentation/virt/geniezone/introduction.rst b/Documentation/virt/geniezone/introduction.rst
> new file mode 100644
> index 000000000000..fb9fa41bcfb8
> --- /dev/null
> +++ b/Documentation/virt/geniezone/introduction.rst
> @@ -0,0 +1,86 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +======================
> +GenieZone Introduction
> +======================
> +
> +Overview
> +========
> +GenieZone hypervisor(gzvm) is a type-1 hypervisor that supports various virtual
"... hypervisor (gzvm) ..."
> +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(gzvm-ko) to leverage the ability of Linux kernel for
"hypervisor kernel driver (also named gzvm) ..."
> +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-ko, the hypervisor would be able to manipulate memory as
s/gzvm-ko/gzvm module/g
> +objects.
> +
> +- Virtual Platform
> +
> +We manage to emulate a virtual mobile platform for guest OS running on guest
> +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
> +mechanisms were to be provided in the future based on VirtIO-vsock.
> +
> +- Device Virtualization
> +
> +The solution is provided using the well-known VirtIO. The gzvm-ko would
> +redirect MMIO traps back to VMM where the virtual devices are mostly emulated.
> +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
> +hypervisor with the help of gzvm-ko, both virtual and physical ones. In case
> +there's no guest VM running out there, physical interrupts would be handled by
> +host VM directly for performance reason. Irqfd is also implemented using
> +eventfd for accepting vIRQ requests in gzvm-ko.
> +
> +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,
> +and it controls the vCPU lifecycle including creating, running and destroying.
> +With self-defined exit handler, the vm component would be able to act
> +accordingly before terminated.
> +
> +- 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
> +vIRQ injection in guest VMs via GIC.
Descriptions for feature lists can be aligned:
---- >8 ----
diff --git a/Documentation/virt/geniezone/introduction.rst b/Documentation/virt/geniezone/introduction.rst
index fb9fa41bcfb8b3..f37ddf4e979992 100644
--- a/Documentation/virt/geniezone/introduction.rst
+++ b/Documentation/virt/geniezone/introduction.rst
@@ -24,63 +24,64 @@ 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.
+ 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-ko, the hypervisor would be able to manipulate memory as
-objects.
+ 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-ko, the hypervisor would be able to manipulate
+ memory as objects.
- Virtual Platform
-We manage to emulate a virtual mobile platform for guest OS running on guest
-VM. The platform supports various architecture-defined devices, such as
-virtual arch timer, GIC, MMIO, PSCI, and exception watching...etc.
+ We manage to emulate a virtual mobile platform for guest OS running on guest
+ 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
-mechanisms were to be provided in the future based on VirtIO-vsock.
+ Communication among guest VMs was provided mainly on RPC. More communication
+ mechanisms were to be provided in the future based on VirtIO-vsock.
- Device Virtualization
-The solution is provided using the well-known VirtIO. The gzvm-ko would
-redirect MMIO traps back to VMM where the virtual devices are mostly emulated.
-Ioeventfd is implemented using eventfd for signaling host VM that some IO
-events in guest VMs need to be processed.
+ The solution is provided using the well-known VirtIO. The gzvm-ko would
+ redirect MMIO traps back to VMM where the virtual devices are mostly
+ emulated. 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
-hypervisor with the help of gzvm-ko, both virtual and physical ones. In case
-there's no guest VM running out there, physical interrupts would be handled by
-host VM directly for performance reason. Irqfd is also implemented using
-eventfd for accepting vIRQ requests in gzvm-ko.
+ All Interrupts during some guest VMs running would be handled by GenieZone
+ hypervisor with the help of gzvm-ko, both virtual and physical ones. In case
+ there's no guest VM running out there, physical interrupts would be handled
+ by host VM directly for performance reason. Irqfd is also implemented using
+ eventfd for accepting vIRQ requests in gzvm-ko.
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.
+ 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,
-and it controls the vCPU lifecycle including creating, running and destroying.
-With self-defined exit handler, the vm component would be able to act
-accordingly before terminated.
+ The vcpu component is the core of virtualizing aarch64 physical CPU runnable,
+ and it controls the vCPU lifecycle including creating, running and
+ destroying. With self-defined exit handler, the vm component would be able to
+ act accordingly before terminated.
- 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
-vIRQ injection in guest VMs via GIC.
+ 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 vIRQ injection in guest VMs via GIC.
Thanks.
--
An old man doll... just what I always wanted! - Clara
Powered by blists - more mailing lists