Re: [Xen-devel] [PATCH 5/6] xen/arm: map reserved-memory regions as normal memory in dom0

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 23 Apr 2019, Julien Grall wrote:
> Hi Stefano,
> 
> On 4/22/19 11:42 PM, Stefano Stabellini wrote:
> > On Tue, 26 Feb 2019, Julien Grall wrote:
> > I am not sure about the suggestion of re-using the libfdt concept of
> > "mem_rsv", which is meant to be for the old /memreserve/. Today, libfdt
> > (at least our version of it) is not able to parse the new
> > reserved-memory bindings. I don't think it is a good idea to modify
> > libfdt for that. Also, the way we want to handle the old memreserve
> > regions is quite different from the way we want to handle
> > reserved-memory, right? I cannot see a way to improve this code using
> > mem_rsv at the moment.
> 
> I didn't mean to extend mem_rsv in libfdt but extend consider_modules and
> dt_unreserved_regions to deal with /reserved-memory. Otherwise you
> may miss some cases (for instance you left out discard_initial_modules).
> 
> By extending those two functions you don't have to teach everyone how to skip
> /reserved-memory.

I think I get your point now. Although I don't think it should be
correct for a bootloader to use a reserved-memory area to store a boot
module, I wouldn't be suprised if that happens, so it is better to be
prepared and extend dt_unreserved_regions. I'll do that.

However, we would still need something like check_reserved_memory,
because we don't want setup_xenheap_mappings to be called on the
reserved-memory area (or a memory region including the reserved memory
area) in setup_mm. I don't think we can get away without it, but I can
simplify it.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel