Re: [PATCH] xen/device-tree: Allow exact match for overlapping regions

[Julien Grall <julien@xxxxxxx>]

On 13/11/2024 16:56, Michal Orzel wrote:
> > > > > For things that Xen can be interested in, only region for ramdisk for dom0 can 
> > > > > match the /memreserve/ region.
> > > > > Providing a generic solution (like Luca did) would want providing an example of 
> > > > > sth else that can match which I'm not aware of.
> > > > I would argue this is the other way around. If we are not certain that
> > > > /memreserve/ will not be used for any other boot module, then we should
> > > > have a generic solution. Otherwise, we will end up with similar weird
> > > > issue in the future.
> > > We have 3 possible modules for bootloader->kernel workflow: kernel, dtb and 
> > > ramdisk. The first 2 are not described in DT so I'm not sure
> > > what are your examples of bootmodules for which you want kernel know about 
> > > memory reservation other than ramdisk.
> > The DTB is not described but the kernel is. We also have XSM modules.
> > All of which could in theory be in memreserve if for some reasons the
> > bootloader wanted to preserve the modules for future use (think
> > Live-Update)...
> >
> > Anyway, to be honest, I don't understand why you are pushing back at a
> > more generic solution... Yes this may be what we just notice today, but
> > I haven't seen any evidence that it never happen.
> >
> > So I would rather go with the generic solution.
> My reluctance comes from the fact that it's difficult for me to later justify 
> (if someone asks) a code like that
> in the port we maintain because I can't answer the question about the rationale 
> of other modules.
You also can't answer why it can't happen. So between the choice of 
trying to be future-proof or handling in an emergency, I would chose the 
former. If you want to handle differently in the AMD port, so be it.
> All you wrote is just a theory.

Hu, seriously? You are basing your decision on observation on a few 
platforms and then you tell me I theorized?
The main source of truth is the specification. This is ...

> Neither you nor anyone seen a code where a bootloader sets up /memreserve/
> for sth else than initrd. That's it.
the only way we can confirm something doesn't happen is based on the 
specification. If it is not written anywhere then it can happen.
I will Nack any patch/approach that is not attempting to look at the 
specification (if any) unless obviously this will break the guest OSes. 
At which point I will weight the pros and cons.
I don't believe this is the case here. So there is no excuses to try to 
take short cut...
Cheers,

--
Julien Grall