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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 20 May 2016, Edgar E. Iglesias wrote:
> 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.

This sounds much nicer that the solution proposed here.

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