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

[Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>]

Oh, Thank you. Clear enough, I would prefer to "pin" remoteproc
mappings, I would say that this is not possible to rewrite pagetable
at any moment of time. For example - during video playback IPU
allocates and frees buffers. The whole amount of memory, mapped to its
MMU is about 256 Mb. If Xen decides to change p2m mappings at this
moment of time, this will lead to significant playback lags. More than
- playback may crash.

Regards,
Andrii

On Wed, Jul 23, 2014 at 1:32 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 22 Jul 2014, Andrii Tseglytskyi wrote:
>> Hi Stefano,
>>
>> On Tue, Jul 22, 2014 at 3:42 PM, Stefano Stabellini
>> <stefano.stabellini@eu.citrix.com> 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@globallogic.com>
>> >> >
>> >> > 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.



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com