[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

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.


Julien Grall

Xen-devel mailing list



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