[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC PATCH 0/9] "Non-shared" IOMMU support on ARM



On 03/15/2017 08:05 PM, Oleksandr Tyshchenko wrote:
Hi, all.

Hi Oleksandr,

Thank you for looking at the support of "non-shared" page table IOMMU support.


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.
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).
And this IOMMU can't share the page table with the CPU since it uses
stage-1 page table unlike the CPU that uses stage-2 therefore I name it
"Non-shared" IOMMU.

I have already raised disscusion [2] about some generic problems I had faced
during porting IPMMU-VMSA Linux driver to Xen. And on this basis I made
patches you can see it in this request. Only the first patch is not related to
IOMMU. But, I decided to ship it with the current request since it is a generic 
change
which we will need in a moment.

The reason for this patch series to be RFC is that I still have some doubts 
about generic code I touched.
I hope that I haven't broken anything for x86, but confirmation is needed.

I didn't include IPMMU-VMSA driver in this request. Although, I am still in 
progress, I want to say
that passthrough use-cases (actually what this all are firstly needed for) work 
for me with some limitations.
I tested on Salvator-X board (R-Car H3) with the next devices that have DMA IPs
connected to IPMMU uTLBs (using current master branch):
1. AUDMA is assigned to dom0 (protected by IOMMU)
2. SDHC0 is assigned to dom1 (passthrough to domain)
3. SDHC3 is assigned to dom2 (passthrough to domain)

I am looking forward to see the support in Xen :).

During porting IPMMU-VMSA driver to Xen I was trying to be as close as possible 
to Linux [1]. But,
it was a little bit difficult). It would be really nice to have some feedback 
and get your feeling regarding this driver.
I am also interested in if I took the right direction or there are some other 
ideas on doing the same.
So, is it a right direction to move on?

I would be interested to know what was the difficulties to port Linux driver in Xen and how much you diverge from it.

My biggest concern is maintainability. It is fair to say that the Linux driver will be more exercised than the Xen driver. By keeping our own, we would potentially have hidden bug that may never be fixed.

By the way, I am not saying we should stick to Linux. I am happy to consider both solutions :).


You can find IPMMU-VMSA driver here.
repo: https://github.com/otyshchenko1/xen.git branch: ipmmu_ml
or
https://github.com/otyshchenko1/xen/commits/ipmmu_ml
It is located on top of "Unshared" IOMMU patch series and consist of 6 patches.

I will have a look.

Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.