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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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.

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