[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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