Re: [Xen-devel] Question about porting IPMMU-VMSA Linux driver to XEN

[Oleksandr Tyshchenko <olekstysh@xxxxxxxxx>]

On Thu, Dec 8, 2016 at 9:39 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
>
>
> On 08/12/16 17:06, Oleksandr Tyshchenko wrote:
>>
>> Hi Julien,
>
>
> Hi Oleksandr,
Hi Julien,

thank you for sharing your opinion.

>
> As discussed on IRC, I CCed xen-devel and Stefano.
>
>> We would like to hear your opinion about the proper way of porting
>> kernel driver to XEN.
>> There is a Linux iommu driver "IPMMU VMSA" for supporting
>> VMSA-compatible IPMMUs that are integrated in the newest Renesas SoCs.
>> Mainline:
>> http://lxr.free-electrons.com/source/drivers/iommu/ipmmu-vmsa.c
>> But we would prefer to rely on code that hasn't reach upstream yet but
>> shipped with BSP for this platform and seems to be more complete:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/horms/renesas-bsp.git/tree/drivers/iommu/ipmmu-vmsa.c?h=v4.6/rcar-3.3.x
>>
>> For passthrough and future Remote processor (coproc) use-cases to work
>> on R-Car Gen3 based platforms we need this driver to be ported to XEN.
>> But I am in doubt how to do this in a right way.
>>
>> So, from my point of view there are two possible ways:
>> 1. Try to keep this driver as close as possible from Linux like you
>> did for arm-smmu driver. Even keeping the Linux style. I understand
>> the main goal despite the overhead and so on.
>> 2. Another way is to try to be as similar as possible from arm-smmu
>> driver in XEN. In such case many common for both drivers things might
>> be moved to the common part.
>
>
> I don't think you would be able to share a lot of code between arm-smmu and
> ipmmu-vmsa. The former is using stage-2 page table whilst ipmmu-vmsa is
> using stage-1 page table. So the page table would have to be unshared in
> your case. This is something we don't yet support on Xen ARM.
>
> Furthermore, I still want to keep arm-smmu as close as possible from Linux
> mainline. When I first implemented the driver I chose to not stick on Linux,
> but we decided to re-sync few months later because it was too hard to
> maintain. One of the main advantage of keeping close to Linux is we can
> backport bug more easily.
I agree.
This is especially important when the driver is "new".
I mean when the driver is intensively developed. This leads to bunch of
fixes, features that should be taken. So, we will likely move in this
direction too.

>
> I would prefer to see ipmmu-vmsa as close as Linux (BSP or mainline), but
> this is not a strong requirement.
I got it.

> Do you know why the changes you are
> looking for are not yet upstreamed? What are the differences?
At the moment I don't know why these changes haven't upstreamed yet.
They look like features and bug fixes in most cases (multi context
support, etc).
So, I think it would be better to rely on the BSP at the first time
and then re-sync with
mainline when these changes reach upstream.

>
> Cheers,
>
> --
> Julien Grall

-- 
Regards,

Oleksandr Tyshchenko

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