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,
> 
> Sorry for the formatting.
> 
> On Tue, 23 Apr 2019, 18:34 Stefano Stabellini, <sstabellini@xxxxxxxxxx> wrote:
>       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.
> 
> 
> Hmmm, setup_xenheap_mappings is only doing the mapping in page-tables 
> allowing direct access in Xen. Are you worried of the
> memory attributes to be different in Xen?

Yes; also we don't need the mappings in Xen.


> This would makes sense however setup_xenheap_mappings may still map the 
> reserved-memory because it is using 1G mapping... This is
> pretty wrong and I have patches that should help to fix it.

I didn't notice it :-/


>  Also if you are concerned with /reserved-memory, then it should also be 
> fixed for /mem-reserve as they are not different.

I understand.


> However, this may break free_initmem as because we try to give back page to 
> xenheap even if they are reserved.
> 
>  The memory management is quite a mess today. I hope to make it better with 
> my upcoming series.

I am going to follow your original suggestion of dropping most of the
changes from this patch and rely on the existing functions.

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