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. Regards, Peng. > > Thanks, > 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.
