Thread (23 messages) 23 messages, 6 authors, 2023-08-31

Re: [PATCH v5 00/12] GenieZone hypervisor drivers

From: Yi-De Wu (吳一德) <hidden>
Date: 2023-08-31 08:10:03
Also in: linux-arch, linux-arm-kernel, linux-doc, linux-mediatek, lkml

On Thu, 2023-08-17 at 15:31 +0800, Yi-De Wu wrote:
On Fri, 2023-08-11 at 10:52 -0600, Rob Herring wrote:
quoted
 	 
External email : Please do not click links or open attachments
until
you have verified the sender or the content.
 On Thu, Jul 27, 2023 at 03:59:53PM +0800, Yi-De Wu wrote:
quoted
This series is based on linux-next, tag: next-20230726.

GenieZone hypervisor(gzvm) is a type-1 hypervisor that supports
various virtual
quoted
machine types and provides security features such as TEE-like
scenarios and
quoted
secure boot. It can create guest VMs for security use cases and
has
virtualization capabilities for both platform and interrupt.
Although the
quoted
hypervisor can be booted independently, it requires the
assistance
of GenieZone
quoted
hypervisor kernel driver(gzvm-ko) to leverage the ability of
Linux
kernel for
quoted
vCPU scheduling, memory management, inter-VM communication and
virtio backend
quoted
support.

Changes in v5:
- Add dt solution back for device initialization
Why? It's a software interface that you define and control. Make
that 
interface discoverable.

Rob
hi Rob,

Let me recap a bit about this as you might not notice our previous
response[1]. In order to discover our GenieZone hypervisor, there
were
2 solutions being talked about, namely with dt or without dt.

The reasons we use dt now were listed in some previous mail
thread[2].
I'll just copy the statements here for better sync-up.
- Although dt is for hardware, it's difficult to discover a specific
hypervisor without probing on all subsystem and thus pollute all of
other users as a consequence.
- The GenieZone hypervisor could be considered as a vendor model to
assist platform virtualization whose implementation is independent
from
Linuxism.

In contrast to the solution with dt, what we were doing was probing
via
hypercall to see whether our hypervisor exists.
However, this could raise some concerns about "polluting all systems"
even for those systems without GenieZone hypervisor embedded[3].

We're wondering if there's any specific implementation in mind from
your side that we could initialize our device in a discoverable
manners
while not affecting other systems. We'll appreciate for the hint.

Regards,

Reference
1. 
https://lore.kernel.org/all/14c0381be38ea40fcd03104bff32bcaa09b920d3.camel@mediatek.com/ (local)
2. 
https://lore.kernel.org/lkml/ea531ba80db67cccb03ea173e714fe868f869e91.camel@mediatek.com/ (local)
3. 
https://lore.kernel.org/all/2fe0c7f9-55fc-ae63-3631-8526a0212ccd@linaro.org/ (local)

Regards,
A gentle ping.

We suppose a simple dt would be a consise solution here to initialize
the GenieZone hypervisor. We also found some other software pieces use
dt as well[4]. Perhaps it could be brought into discussion that dt
shall be suitable under our use case.

Reference
4. OP-TEE Trusted OS maintained by Linaro

https://elixir.bootlin.com/linux/v6.1/source/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.yaml
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help