Hi, > On 11 Oct 2022, at 00:58, Stefano Stabellini <sstabell...@kernel.org> wrote: > > 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
I agree with that but if we make an assumption that something is bogus, we should at least warn the user if possible. Bertrand
