Message-ID: <d9986bc048468ab30a63a3cd570df3c5b1e933e5.camel@mediatek.com>
Date: Tue, 22 Oct 2024 02:21:22 +0000
From: Liju-clr Chen (陳麗如)
	<Liju-clr.Chen@...iatek.com>
To: "corbet@....net" <corbet@....net>, AngeloGioacchino Del Regno
	<angelogioacchino.delregno@...labora.com>, "rdunlap@...radead.org"
	<rdunlap@...radead.org>, "rostedt@...dmis.org" <rostedt@...dmis.org>,
	Ze-yu Wang (王澤宇) <Ze-yu.Wang@...iatek.com>,
	"catalin.marinas@....com" <catalin.marinas@....com>, "conor+dt@...nel.org"
	<conor+dt@...nel.org>, "robh@...nel.org" <robh@...nel.org>,
	"richardcochran@...il.com" <richardcochran@...il.com>, "mhiramat@...nel.org"
	<mhiramat@...nel.org>, Yingshiuan Pan (潘穎軒)
	<Yingshiuan.Pan@...iatek.com>, "matthias.bgg@...il.com"
	<matthias.bgg@...il.com>, "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
	"mathieu.desnoyers@...icios.com" <mathieu.desnoyers@...icios.com>,
	"will@...nel.org" <will@...nel.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-trace-kernel@...r.kernel.org" <linux-trace-kernel@...r.kernel.org>,
	"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
	Kevenny Hsieh (謝宜芸)
	<Kevenny.Hsieh@...iatek.com>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, PeiLun Suei (隋培倫)
	<PeiLun.Suei@...iatek.com>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, Shawn Hsiao (蕭志祥)
	<shawn.hsiao@...iatek.com>, "linux-doc@...r.kernel.org"
	<linux-doc@...r.kernel.org>, Chi-shen Yeh (葉奇軒)
	<Chi-shen.Yeh@...iatek.com>
Subject: Re: [PATCH v12 02/24] docs: geniezone: Introduce GenieZone hypervisor

On Tue, 2024-07-30 at 07:13 -0700, Randy Dunlap wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  Hi--
> 
> On 7/30/24 1:24 AM, Liju-clr Chen wrote:
> > From: Yingshiuan Pan <yingshiuan.pan@...iatek.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@...iatek.com>
> > Co-developed-by: Yi-De Wu <yi-de.wu@...iatek.com>
> > Signed-off-by: Yi-De Wu <yi-de.wu@...iatek.com>
> > Signed-off-by: Liju Chen <liju-clr.chen@...iatek.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
> 
Hi Randy,
Sure, thank you for your comment.
Will update in next version.

> > +  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

BR
Liju

Powered by blists - more mailing lists