Re: [Embedded-pv-devel] [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0

["Edgar E. Iglesias" <edgar.iglesias@xxxxxxxxx>]

On Fri, May 20, 2016 at 04:04:43PM +0100, Julien Grall wrote:
> Hello Oleksandr,
> 
> On 20/05/16 15:19, Oleksandr Dmytryshyn wrote:
> >On Fri, May 20, 2016 at 12:59 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> >>>>>On 20.05.16 at 10:45, <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx> wrote:
> >>>On Thu, May 19, 2016 at 5:36 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> >>>>>>>On 19.05.16 at 15:58, <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx> wrote:
> >>>>>Case 1: Dom0 is driver domain:
> >>>>>There is a Ducati firmware which runs on dedicated M4 core and decodes
> >>>>>video. This firmware uses hardcoded physical addresses for graphics
> >>>>>buffers. Those addresses should be inside address-space of the driver
> >>>>>domain (Dom0). Ducati firmware is proprietary and we have no ability
> >>>>>to rework it. So Dom0 kernel should be placed to the configured
> >>>>>address (to the DOM0 RAM bank with specific address).
> >>>>>
> >>>>>Case 2: Dom0 is Thin and DomD is driver domain.
> >>>>>All is the same: Ducati firmware requires special (hardcoded) addresses.
> >>>>
> >>>>For both of these cases I would then wonder whether such
> >>>>environments are actually suitable for doing virtualization on.
> >>>Currently we use Jacinto 6 evaluation board with DRA74X processor.
> >>>We have both configurations (Thin Dom0 and Thich Dom0).
> >>
> >>Which says nothing about their suitability for virtualization.
> >Our solution is based on Jacinto 6 evaluation board with DRA74X
> >processor. We need video-playback. Ducati firmware decodes video and
> >it works only with hardcoded addresses so we need this patch.
> 
> This patch is a way to solve the problem and may not be the only one.
> I would like to explore all the possibilities before taking an approach that
> requires to modify the memory allocator in Xen.
> 
> In my previous mails, I suggested a different solution (see [1] and [2]). If
> you think it is not suitable, please share more details or explain why you
> think your patch is the only way to solve it.

Hi,

We have similar needs (not exactly the same) in some of our setups.
We need to map certain OCMs (On Chip Memories) to dom0. Among other things,
these are used to communicate with remote accelerators/CPUs that have
"hardcoded" addresses to these RAMs.

Our approach is more along the lines of Juliens second suggestion. We're
trying to use the mmio-sram DTS bindings to bring in these memories into
dom0.

IIUC the Ducati FW issue correctly, you need to allocate a chunk of DDR.

Another possible solution:
I think you could reserve the memory area by simply not mentioning it
in the main memory node (these nodes support multiple ranges so you can
introduce gaps). Then you could for example create an mmio-sram node to
get the memory explicitely mapped 1:1 into dom0.

Just a moment ago, I posted an RFC for the mmio-sram support to the list.

Cheers,
Edgar


> 
> Regards,
> 
> [1]
> http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01879.html
> [2]
> http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg01894.html
> 
> -- 
> Julien Grall
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Embedded-pv-devel mailing list
Embedded-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/embedded-pv-devel