[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

> Jan
>

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.