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

[Oleksandr Dmytryshyn <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx>]

Oleksandr Dmytryshyn | Product Engineering and Development
GlobalLogic
M +38.067.382.2525
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt


On Thu, May 19, 2016 at 5:34 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
> Hello Oleksandr,
>
>
> On 19/05/16 14:58, Oleksandr Dmytryshyn wrote:
>>>
>>> Why would a user want to allocate DOM0 RAM bank to a specific address?
>>>
>>> If I understand correctly your patch, DOM0 will only able to allocate one
>>> bank of the given size at the specific address. You also add this
>>> possibility for guest domain (see patch #4) and try to control where the
>>> guest memory will be allocated. This will increase a lot the chance of the
>>> memory allocation to fail.
>>>
>>> For instance, the RAM region requested for DOM0 may have been used to
>>> allocate memory for Xen internal. So you need a way to reserve memory in
>>> order to avoid Xen using it.
>>>
>>> I expect most of the users who want to use direct memory mapped guest to
>>> know the number of guests which will use this feature.
>>>
>>> A such feature is only useful when pass-through a device to the guest on
>>> platfom without SMMU, so it is by default insecure.
>>>
>>> So I would suggest to create a new device-tree binding (or re-use an
>>> actual one) to reserve memory region to be used for direct memory mapped
>>> domain.
>>>
>>> Those regions could have an identifier to be used later during the
>>> allocation. This would avoid memory fragmentation, allow multiple RAM bank
>>> for DOM0,...
>>>
>>> Any opinions?
>>
>>
>> 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.
>
>
> So if I understand correctly, patches #4, #13, #16 are only here to
> workaround a firmware which does not do the right thing?
>
> IHMO, modifying the memory allocator in Xen to make a firmware happy is just
> overkill. We need to explore all the possible solutions before going
> forward.
Yes, You are right. This patch written to make a firmware happy.

> From your description, it looks like to me that the device-tree does not
> correctly describe the platform. The graphic buffers should be reserved
> using /memreserve or via a specific binding.
>
> This would be used later by Xen to map the buffer into dom0 or allow dom0 to
> map it to a guest.
>
> Regards,
>
> --
> Julien Grall

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