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

[Julien Grall <julien.grall@xxxxxxx>]

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

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