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

[Oleksandr Tyshchenko <olekstysh@xxxxxxxxx>]

Hi Stefano

On Sat, Dec 10, 2016 at 2:45 AM, Stefano Stabellini
<sstabellini@xxxxxxxxxx> wrote:
> On Thu, 8 Dec 2016, Oleksandr Tyshchenko wrote:
>> 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.
>
> I am not completely against importing a non-upstream driver, but be
> careful because not being upstream means that it hasn't been reviewed as
> much as the upstream counterpart. It might have bugs. Once it reaches
> upstream, it might be different and hard to sync.

I got your point. I will keep in mind it.

Thank you.

-- 
Regards,

Oleksandr Tyshchenko

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