Re: [RFC PATCH v1 0/7] IPMMU-VMSA support on ARM

[Julien Grall <julien.grall@arm.com>]

On 01/08/17 18:13, Oleksandr Tyshchenko wrote:
> Hi, Julien
>
> On Tue, Aug 1, 2017 at 3:27 PM, Julien Grall <julien.grall@arm.com> wrote:
>> On 26/07/17 16:09, Oleksandr Tyshchenko wrote:
>>>
>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>
>>> Hi, all.
>>
>>
>> Hi,
>>
>> Please CC maintainers and any relevant person on the cover letter. This is
>> quite useful to have in the inbox.
> Yes. I CCed guys who, I think, are/were involved in IPMMU-VMSA
> development from Linux side +
> IOMMU maintainers (mostly ARM). Sorry, if I missed someone or mistakenly added.
>
>>
>>> The purpose of this patch series is to add IPMMU-VMSA support to Xen on
>>> ARM.
>>> 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 doesn't
>>> use the same page-table format
>>> as the CPU on ARM therefore I name it "Non-shared" IOMMU.
>>> This all means that current patch series must be based on "Non-shared"
>>> IOMMU support [1]
>>> for the IPMMU-VMSA to be functional inside Xen.
>>>
>>> The IPMMU-VMSA driver as well as the ARM LPAE allocator were directly
>>> ported from BSP for Linux the vendor provides:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git
>>> rcar-3.5.3
>>
>>
>> I think this is probably a good starting point to discuss about IOMMU
>> support in Xen. I skimmed through the patches and saw the words "rfc" and
>> "ported from BSP".
> Well, at the time of porting IPMMU-VMSA driver, BSP [1] had more
> complete support than mainline [2]
> and seems to have at the moment.
> For example, mainline driver still has single IPMMU context while BSP
> driver can have up to 8 contexts,
> the maximum uTLBs mainline driver can handle is 32, but for BSP driver
> this value was increased to 48, etc.
> But, I see attempts to get all required support in [3]. So, when this
> support reaches upsteam, I hope,
> it won't be a big problem to rebase on mainline driver if we decide to
> align with it.

My main concern here is this driver haven't had a thorough review by the 
Linux community.

When we ported the SMMUv{1,2} driver we knew the Linux community was 
happy with it and hence adapting for Xen was not a big deal. There are 
only few limited changes in the code from Linux.

Looking at patch #2, #6, #7, the changes don't seem limited in the code 
from Linux + it is a driver from a BSP. The code really needs to be very 
close to make the port from Linux really worth it.

Stefano do you have any opinion?

>
>>
>> At the moment for IOMMU we rely on the Linux community to do the review, but
>> this is not the case here as it is an RFC.  I can definitely help to check
>> if it comply for Xen,
> yes, please.
>
>> but I don't have the competence to tell whether it is
>> valid for the hardware.
>>
>> We may want to find a compromise to get it merged in Xen, but surely we
>> don't want to build it by default at least until we had feedback from the
>> community about the validity of the code here.
> agree.
>
>>
>> As I mentioned above, we are currently borrowing drivers from Linux and
>> adapting for Xen. Today we support SMMUv{1,2} (we need to resync it) and
>> there are plan to add IPMMU-VMSA (this series) and SMMUv3.
> It would be really nice to have IPMMU-VMSA support in Xen. Without
> this support the SCF [4] we are developing right now
> and even the Passthrough feature won't be fully functional on R-Car
> Gen3 based boards powered by Xen hypervisor.

As said in the previous e-mail. This would be nice enhancement for Xen, 
but we need to decide in which form it will be upstreamed.

>
>>
>> I am aware that Linux IOMMU subsystem has growing quite a lot making more
>> tricky to get support in Xen. I wanted to get feedback how complex from you
>> and Sameer how complex it was and whether we should consider doing our own.
>
> Yes, the IPMMU-VMSA Linux driver relies on some Linux functional
> (IOMMU/DMA/io-pgtable frameworks) the Xen doesn't have (it is
> expected). So, it took *some time*
> to make Linux driver happy inside Xen). Moreover, this all resulted in
> the fact that the driver looks complicated a bit).
> A lot of different wrappers, #if 0, code style, etc.
> On the other hand, I think, I will be able to fairly quickly align
> with new BSP, etc.
>
> But, I really don't know should we continue to follow this direction
> or not, perhaps it will depend on
> how complex the entity is and how much things we must pull together
> with it to make it happy.
>

Cheers,

-- 
Julien Grall

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