On Mon, 10 Oct 2022, Jan Beulich wrote:
> On 08.10.2022 21:08, Julien Grall wrote:
> > On 06/10/2022 15:11, Jan Beulich wrote:
> >>> ... the space cannot become ordinary RAM, then such a precaution
> >>> wouldn't be necessary. After all hiding EfiACPIReclaimMemory from
> >>> Dom0 just because it can't be mapped WB wouldn't be very nice
> >>> either. I guess I'll submit v2 with this part of the change left
> >>> as it was.
> >>
> >> And while already in the process of committing the patch I came to
> >> realize that if the WB conditional isn't supposed to move, isn't
> >> the change done for Arm then wrong as well? Shouldn't it then be
> >>
> >>          if ( !(desc_ptr->Attribute & EFI_MEMORY_RUNTIME) &&
> >>               (desc_ptr->Attribute & EFI_MEMORY_WB) &&
> >>               (desc_ptr->Type == EfiConventionalMemory ||
> >>               ...
> >>
> >> leaving the EfiACPIReclaimMemory case entirely unaffected by the
> >> change?
> > 
> > IIUC, the concern is the region EfiACPIReclaimMemory could have the attribute EFI_MEMORY_RUNTIME. Is that correct?
> 
> Yes, ...
> 
> > Given that the memory is reclaimable, I am not sure why it can also have this atribute set (to me it means the opposite).
> 
> ... at least on x86 all sorts of strange/bogus type/attribute combinations
> have been observed.

Yeah... it is a good idea to be able to cope with strange and bogus
firmware tables as it is known to happen