On 12.03.2024 14:22, Marek Marczykowski-Górecki wrote: > On Tue, Mar 12, 2024 at 02:09:14PM +0100, Marek Marczykowski-Górecki wrote: >> On Tue, Mar 12, 2024 at 01:38:53PM +0100, Jan Beulich wrote: >>> On 12.03.2024 13:02, Marek Marczykowski-Górecki wrote: >>>> BTW should e820_change_range_type() return 1 in case of mapping already >>>> having the right type? Otherwise, if one wants to use >>>> iommu_add_extra_reserved_device_memory() on already reserved memory, the >>>> e820_change_range_type() would fail. >>> >>> You raised that question on Matrix yesterday, iirc, and I left it >>> unanswered there because it takes archeology to find the answer (or at >>> least get closer to one). And, please don't get me wrong, you could as >>> well do that yourself. (My vague recollection from having dealt with >>> similar code in Linux is that yes, in the example given the function >>> ought to indeed have failed back then. Depending on present uses etc >>> it may well be that we could reconsider, though.) >> >> I sure can do some archaeology there, I was just hoping any of you would >> know the answer already. > > None of the commit messages touching that code give the answer. But > looking around, most callers of reserve_e820_ram() ignore its return > value. One exception is reserving memory for kexec. I guess in that case > it may be intentional to fail if the area is reserved already, as it may > indicate it cannot be used for kexec. Is that correct?
I suppose so, yes. > There are also a couple of calls to e820_change_range_type() in tboot > code where it changes E820_RESERVED to E820_UNUSABLE. There, I guess > changing e820_change_range_type() behavior would be okay. Possibly, but please don't put much trust in the tboot code we have. Jan
