diff mbox series

[v7,01/16] docs: geniezone: Introduce GenieZone hypervisor

Message ID 20231116152756.4250-2-yi-de.wu@mediatek.com (mailing list archive)
State New
Headers show
Series GenieZone hypervisor drivers | expand

Commit Message

Yi-De Wu Nov. 16, 2023, 3:27 p.m. UTC
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>
Signed-off-by: Liju Chen <liju-clr.chen@mediatek.com>
Signed-off-by: Yi-De Wu <yi-de.wu@mediatek.com>
---
 Documentation/virt/geniezone/introduction.rst | 86 +++++++++++++++++++
 Documentation/virt/index.rst                  |  1 +
 MAINTAINERS                                   |  6 ++
 3 files changed, 93 insertions(+)
 create mode 100644 Documentation/virt/geniezone/introduction.rst

Comments

Bagas Sanjaya Nov. 20, 2023, 10:58 a.m. UTC | #1
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.
diff mbox series

Patch

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
+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
+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
+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.
diff --git a/Documentation/virt/index.rst b/Documentation/virt/index.rst
index 7fb55ae08598..cf12444db336 100644
--- a/Documentation/virt/index.rst
+++ b/Documentation/virt/index.rst
@@ -16,6 +16,7 @@  Virtualization Support
    coco/sev-guest
    coco/tdx-guest
    hyperv/index
+   geniezone/introduction
 
 .. only:: html and subproject
 
diff --git a/MAINTAINERS b/MAINTAINERS
index b294edaf5698..b4f7ff186619 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8942,6 +8942,12 @@  F:	include/vdso/
 F:	kernel/time/vsyscall.c
 F:	lib/vdso/
 
+GENIEZONE HYPERVISOR DRIVER
+M:	Yingshiuan Pan <yingshiuan.pan@mediatek.com>
+M:	Ze-Yu Wang <ze-yu.wang@mediatek.com>
+M:	Yi-De Wu <yi-de.wu@mediatek.com>
+F:	Documentation/virt/geniezone/
+
 GENWQE (IBM Generic Workqueue Card)
 M:	Frank Haverkamp <haver@linux.ibm.com>
 S:	Supported