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

[Oleksandr Dmytryshyn <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx>]

> 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.

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