|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 00/13] "Non-shared" IOMMU support on ARM
Hi, Kevin On Tue, Aug 1, 2017 at 6:06 AM, Tian, Kevin <kevin.tian@xxxxxxxxx> wrote: >> From: Oleksandr Tyshchenko [mailto:olekstysh@xxxxxxxxx] >> Sent: Monday, July 31, 2017 7:58 PM >> >> Hi, Kevin >> >> On Mon, Jul 31, 2017 at 8:57 AM, Tian, Kevin <kevin.tian@xxxxxxxxx> wrote: >> >> From: Oleksandr Tyshchenko >> >> Sent: Wednesday, July 26, 2017 1:27 AM >> >> >> >> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx> >> >> >> >> Hi, all. >> >> >> >> The purpose of this patch series is to create a base for porting >> >> any "Non-shared" IOMMUs to Xen on ARM. Saying "Non-shared" IOMMU >> I >> >> mean >> >> the IOMMU that can't share the page table with the CPU. >> > >> > Is "non-shared" IOMMU a standard terminology in ARM side? I quickly >> > searched to find it mostly used in this thread... >> I don't think that it is a standard terminology. >> >> > >> > On the other hand, all IOMMUs support a basic DMA remapping >> > mechanism with page table not shared with CPU. Then some IOMMUs >> > may optional support Shared Virtual Memory (SVM) through page >> > sharing with CPU. Then I'm not sure why need to highlight the >> > "non-shared" manner in this thread, instead of just saying >> > IPMMU-VMSA support... >> I wouldn't use "IPMMU-VMSA support" in this thread since it may be any >> other IOMMUs which can't share page table >> with CPU because of format incompatibilities. > > As I commented you can assume all IOMMUs cannot share page > table with CPU as the starting point. It's not good to name an IOMMU > driver based on such fact. > >> I needed something short to describe such IOMMUs, but, If title >> "non-shared" IOMMU sounds confusing >> I won't use it anymore. Do you have something in mind? > > IOMMU driver needs to be vendor specific. Is your driver working > for all IPMMU-VMSA compatible IOMMUs or only for Renesas? > If the latter, you may make the name explicit for such purpose. > > btw since you're porting Linux driver to Xen. What 's the name > used in Linux side? that should be a good reference to you. I am afraid a misunderstanding took place. Let me elaborate a bit more about this. The IOMMU driver I am porting to Xen is IPMMU-VMSA [1]. This name is used in Linux and this name was retained during porting to Xen. This driver is intended to work with Renesas VMSA-compatible IPMMUs. But, IPMMU-VMSA support is not a target for the current thread, there is another thread for adding it [2]. The purpose of the current thread is to create ground for IPMMU-VMSA IOMMUs (as well as other IOMMUs which can't share page table with CPU because of format incompatibilities) to be functional inside Xen on ARM. The only IOMMU supported today in Xen on ARM is the ARM SMMU (which uses the same page table format as the CPU and can share page table with it). And ARM specific code assumes that P2M table is *always* shared and acts accordingly. So, this patch series is trying to, let's say, brake this assumption and create environment to handle such IOMMUs as well. So, I may use the whole sentence as a patch series title in order not to confuse people: "Support IOMMUs which don't share page table with the CPU on ARM" No objections? P.S. This patch series also touches x86 specific code, it's because I had to modify common code. [1] http://elixir.free-electrons.com/linux/latest/source/drivers/iommu/ipmmu-vmsa.c [2] https://lists.xen.org/archives/html/xen-devel/2017-07/msg02679.html > >> >> > >> >> Primarily, we are interested in IPMMU-VMSA and I hope that it will be the >> >> first candidate. >> >> It is VMSA-compatible IOMMU that integrated in the newest Renesas R- >> Car >> >> Gen3 SoCs (ARM). >> >> I am about to push IPMMU-VMSA support in a while. >> >> >> >> With regard to the patch series, it was rebased on Xen 4.9.0 release and >> >> tested on Renesas R-Car Gen3 >> >> H3/M3 based boards with applied IPMMU-VMSA support: >> >> - Patches 1 and 3 have Julien's Rb. >> >> - Patch 2 has Jan's Rb but only for x86 and generic parts. >> >> - Patch 4 has Julien's Ab. >> >> - Patches 5,6,9,10 were slightly reworked. >> >> - Patch 7 was significantly reworked. The previous patch -> iommu: Split >> >> iommu_hwdom_init() into arch specific parts >> >> - Patches 8,11,12,13 are new. >> >> >> >> Not really sure about x86-related changes since I had no possibility to >> check. >> >> So, compile-tested on x86. >> >> >> >> You can find current patch series here: >> >> repo: https://github.com/otyshchenko1/xen.git branch: >> >> non_shared_iommu_v2 >> >> >> >> Previous patch series here: >> >> [PATCH v1 00/10] "Non-shared" IOMMU support on ARM >> >> https://www.mail-archive.com/xen-devel@xxxxxxxxxxxxx/msg107532.html >> >> >> >> [RFC PATCH 0/9] "Non-shared" IOMMU support on ARM >> >> https://www.mail-archive.com/xen-devel@xxxxxxxxxxxxx/msg100468.html >> >> >> >> Thank you. >> >> >> >> Oleksandr Tyshchenko (13): >> >> xen/device-tree: Add dt_count_phandle_with_args helper >> >> iommu: Add extra order argument to the IOMMU APIs and platform >> >> callbacks >> >> xen/arm: p2m: Add helper to convert p2m type to IOMMU flags >> >> xen/arm: p2m: Update IOMMU mapping whenever possible if page table >> is >> >> not shared >> >> iommu/arm: Re-define iommu_use_hap_pt(d) as iommu_hap_pt_share >> >> iommu: Add extra use_iommu argument to iommu_domain_init() >> >> iommu: Make decision about needing IOMMU for hardware domains in >> >> advance >> >> iommu/arm: Misc fixes for arch specific part >> >> xen/arm: Add use_iommu flag to xen_arch_domainconfig >> >> xen/arm: domain_build: Don't expose IOMMU specific properties to the >> >> guest >> >> iommu/arm: smmu: Squash map_pages/unmap_pages with >> >> map_page/unmap_page >> >> [RFC] iommu: VT-d: Squash map_pages/unmap_pages with >> >> map_page/unmap_page >> >> [RFC] iommu: AMD-Vi: Squash map_pages/unmap_pages with >> >> map_page/unmap_page >> >> >> >> tools/libxl/libxl_arm.c | 8 + >> >> xen/arch/arm/domain.c | 2 +- >> >> xen/arch/arm/domain_build.c | 10 ++ >> >> xen/arch/arm/p2m.c | 10 +- >> >> xen/arch/x86/domain.c | 2 +- >> >> xen/arch/x86/mm.c | 11 +- >> >> xen/arch/x86/mm/p2m-ept.c | 21 +-- >> >> xen/arch/x86/mm/p2m-pt.c | 26 +--- >> >> xen/arch/x86/mm/p2m.c | 38 +---- >> >> xen/arch/x86/x86_64/mm.c | 5 +- >> >> xen/common/device_tree.c | 7 + >> >> xen/common/grant_table.c | 10 +- >> >> xen/drivers/passthrough/amd/iommu_map.c | 212 >> +++++++++++++++---- >> >> ------- >> >> xen/drivers/passthrough/amd/pci_amd_iommu.c | 10 +- >> >> xen/drivers/passthrough/arm/iommu.c | 7 +- >> >> xen/drivers/passthrough/arm/smmu.c | 23 ++- >> >> xen/drivers/passthrough/iommu.c | 73 ++++----- >> >> xen/drivers/passthrough/vtd/iommu.c | 116 +++++++++----- >> >> xen/drivers/passthrough/vtd/x86/vtd.c | 4 +- >> >> xen/drivers/passthrough/x86/iommu.c | 6 +- >> >> xen/include/asm-arm/iommu.h | 4 +- >> >> xen/include/asm-arm/p2m.h | 34 +++++ >> >> xen/include/asm-x86/hvm/svm/amd-iommu-proto.h | 8 +- >> >> xen/include/public/arch-arm.h | 5 + >> >> xen/include/xen/device_tree.h | 19 +++ >> >> xen/include/xen/iommu.h | 24 +-- >> >> 26 files changed, 402 insertions(+), 293 deletions(-) >> >> >> >> -- >> >> 2.7.4 >> >> >> >> >> >> _______________________________________________ >> >> Xen-devel mailing list >> >> Xen-devel@xxxxxxxxxxxxx >> >> https://lists.xen.org/xen-devel >> >> >> >> -- >> Regards, >> >> Oleksandr Tyshchenko -- Regards, Oleksandr Tyshchenko _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |