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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-06-26 at 14:07 +0300, 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.

Just to clarify the model:

This is intended as a framework to enable Xen to provide an SMMU to the
guest. Is the intention that this SMMU be an idealised PV thing or is it
intending to emulate a real SMMU (and therefore the guests existing
drivers)? I think this is the second one.

And the intention here is to let the guest manipulate the page tables
directly and shadow them from IPA->MA as opposed to e.g. exposing the
guest's complete IPA->MA mapping to the remoteproc.

I suppose either way my main concern is going to be the potential for
proliferation of backends (and perhaps frontends) for all sorts of
different H/W MMUs. I suppose that is unavoidable though.

WRT the shadowing, I don't see the bit which causes the guest pages
which it is using as PT page for the remoteproc to get marked R/O to
force a trap. Perhaps that comes later.

Do these remoteproc page tables get frequently updated at run time or
are they mostly just build once and forget?

Ian.


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