On 22.03.19 14:14, Peng Fan wrote:
Hi Jan,
-----Original Message-----
From: Jan Kiszka [mailto:[email protected]]
Sent: 2019年3月22日 19:55
To: Lokesh <[email protected]>; Jailhouse
<[email protected]>
Cc: Peng Fan <[email protected]>; Tero Kristo <[email protected]>; Sekhar
Nori <[email protected]>
Subject: Re: [RFC PATCH 5/5] arm64: iommu: smmu-v3: Add support for
stage-2 translations
On 22.03.19 10:44, 'Lokesh' via Jailhouse wrote:
From: Lokesh Vutla <[email protected]>
A System Memory Management Unit(SMMU) performs a task analogous to
a
CPU's MMU, translating addresses for device requests from system I/O
devices before the requests are passed into the system interconnect.
Implement a driver for SMMU v3 that maps and unmaps memory for
specified stream ids. This driver supports only stage 2 translation
and right now inmates cannot enable stage 1 translations. Because of
this limitation, only assignment of device to a guest VM is supported.
For isolation and scatter-gather features stage-1 translation should
be clubbed along with the existing driver.
What is meant with "scatter-gather features"?
This driver is implemented based on the following assumptions:
- Running on a Little endian 64 bit core compatible with ARM v8
architecture
- SMMU supporting only AARCH64 mode
- SMMU AARCH 64 stage 2 translation configurations are compatible with
ARMv8 VMSA. So re using the translation tables of CPU for SMMU.
Inorder to enable stage 1 translations by cells, jailhouse should
implement a emulated smmu driver that traps all smmu ste/translation
updates. Only these updates are trapped jailhouse should do policing
on the updates and make the updates in the proper locations.
Sounds frightening - complexity-wise, but also performance-wise. Do we have
a feeling for both, based on Linux experiences?
This driver is loosely based on the Linux kernel SMMU v3 driver.
Signed-off-by: Lokesh Vutla <[email protected]>
---
hypervisor/arch/arm64/Kbuild | 2 +-
hypervisor/arch/arm64/smmu-v3.c | 1017
++++++++++++++++++++++++++
hypervisor/include/jailhouse/entry.h | 1 +
3 files changed, 1019 insertions(+), 1 deletion(-)
create mode 100644 hypervisor/arch/arm64/smmu-v3.c
How does this implementation roughly compare to
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource
.codeaurora.org%2Fexternal%2Fimx%2Fimx-jailhouse%2Fcommit%2F%3Fh%
3Dimx_4.14.78_1.0.0_ga%26id%3D3ff00cf2e5a3c3197cbdeb668dfe90afa8f1
076e&data=02%7C01%7Cpeng.fan%40nxp.com%7Cb2453af080ba4cc88
c7308d6aebd48bb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C
636888525323999538&sdata=hDW9en44FuAqllOQBq8ht6Hs5wT08W%
2FPFCQa%2FOcWgkg%3D&reserved=0?
The driver has a similar size, that's what I can see quickly, but I guess you
folks
(including Peng) can explain quicker the differences, if there are significant
ones. Of course, the maintainer would prefer to have best of all worlds in the
end upstream :).
The smmu driver in imx-jailhouse tree is for smmu-v2, smmu-v2 and v3 are
different,
I think that why Linux kernel also has two drivers, smmu.c and smmu-v3.c.
Ah, thanks for clarifying. That is a... relevant difference. I wasn't expecting
v2 in the wild anymore.
OK, so we will need two rather different drivers in the end. A pity.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
