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

[Julien Grall <julien.grall@arm.com>]

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.

 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

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