Re: [Xen-devel] [PATCH v02 1/7] arm: introduce remoteprocessor iommu module

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 22 Jul 2014, Andrii Tseglytskyi wrote:
> Hi Stefano,
> 
> On Tue, Jul 22, 2014 at 3:42 PM, Stefano Stabellini
> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > On Wed, 16 Jul 2014, Ian Campbell wrote:
> >> On Fri, 2014-07-04 at 14:59 +0100, Stefano Stabellini wrote:
> >> > On Thu, 26 Jun 2014, Andrii Tseglytskyi wrote:
> >> > > This is a fisrst patch from patch series which was
> >> > > developed to handle remote (external) processors
> >> > > memory management units. Remote processors are
> >> > > typically used for graphic rendering (GPUs) and
> >> > > high quality video decoding (IPUs). They are typically
> >> > > installed on such multimedia SoCs as OMAP4 / OMAP5.
> >> > >
> >> > > As soon as remoteprocessor MMU typically works with
> >> > > pagetables filled by physical addresses, which are
> >> > > allocated by domU kernel, it is almost impossible to
> >> > > use them under Xen, intermediate physical addresses
> >> > > allocated by kernel, need to be translated to machine
> >> > > addresses.
> >> > >
> >> > > This patch introduces a simple framework to perform
> >> > > pfn -> mfn translation for external MMUs.
> >> > > It introduces basic data structures and algorithms
> >> > > needed for translation.
> >> > >
> >> > > Typically, when MMU is configured, some it registers
> >> > > are updated by new values. Introduced frameworks
> >> > > uses traps as starting point of remoteproc MMUs
> >> > > pagetables translation.
> >> > >
> >> > > Change-Id: Ia4d311a40289df46a003f5ae8706c150bee1885d
> >> > > Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@xxxxxxxxxxxxxxx>
> >> >
> >> > There is one problem with this patch: you need to find a way to "pin"
> >> > the p2m entries for the pfns and mfns found in the pagetables translated
> >> > by remoteproc_iommu.c.  Otherwise Xen might decide to change the pfn to
> >> > mfn mappings for the domain, breaking the pagetables already translated
> >> > by remoteproc_iommu.c.  pfn to mfn mappings are not guaranteed to be
> >> > stable. At the moment Xen on ARM wouldn't change pfn to mfn mappings
> >> > under the guest feet, but features like memory sharing or swapping,
> >> > supported on x86, could cause it to happen.
> >>
> >> I've not fully grokked this patch but wouldn't it be easier and better
> >> to have a hook to cause the remoteproc to throw away and rebuild its
> >> mappings when this happens? It could be called from e.g. the TLB flush
> >> associated with the p2m changing, I think.
> >
> > I guess it depends on how often Xen or the Xen tools are going to change
> > the p2m for a running domain. For example changing one page mapping a
> > couple of times a second would be very expensive if we have to rebuild
> > the remoteproc pagetables every time.
> 
> Sorry, I didn't get the point here. Looks like you are talking about
> TLB flush initiated by Xen? Am I right?

p2m stands for physical to machine (mappings) or IPA to PA using ARM
terminology. Xen is free to change IPA to PA mappings of a VM without
the VM knowing, while the VM is running. Nothing in Xen on ARM does it
yet, but a few features do it today on Xen on x86. For example memory
sharing and swapping.

My first suggestion was to "pin" the p2m mappings of pages used in
remoteproc pagetables, so that their IPA to PA mappings wouldn't change.
Ian suggested to rebuild the remoteproc pagetables if one of the IPA to
PA mappings change.
My reply here is that the performance could suffer if IPA to PA mappings
are changed often enough.

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