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
